Re: Re: [qmailtoaster] queue is flooding user
xlogicmx.net) >>>> (187.234.134.4) >>>>by ns1.bizmailserver.net with SMTP; 8 Oct 2015 17:19:26 - >>>> Received-SPF: unknown (ns1.bizmailserver.net: domain at listrak does >>>> not designate permitted sender hosts) >>>> Received: from redbrokerage.com.inbound10.mxlogicmx.net >>>> (redbrokerage.com.inbound10.mxlogicmx.net [208.65.144.3]) >>>> by redbrokerage.com (Outbound Mail Relay) with ESMTP id >>>> yZSt49AdKNeARht0 >>>> for<bandu_p-...@poseidonship.com>; Thu, 08 Oct 2015 13:19:29 >>>> -0400 (EDT) >>>> MIME-Version: 1.0 >>>> Message-ID:<5616a5a1.3ff1f...@redbrokerage.com.inbound10.mxlogicmx.net> >>>> Date: Thu, 08 Oct 2015 13:15:29 -0400 >>>> From: "Noemie Considine"<agulle...@redbrokerage.com> >>>> To:bandu_p-...@poseidonship.com >>>> Subject: contract >>>> Content-Type: multipart/mixed; >>>> boundary="070709070301020805080405" >>>> --070709070301020805080405 >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> >>>> Dear customer, >>>> >>>> I'm sending you a new contract of the project (Private collateral >>>> statement of account) >>>> >>>> --070709070301020805080405 >>>> Content-Type: application/zip; name="Private collateral statement of >>>> account.zip" >>>> Content-Description: "Private collateral statement of account.doc" >>>> Content-Disposition: attachment; filename="Private collateral >>>> statement of account.zip"; size=43024; >>>> creation-date="Thu, 08 Oct 2015 13:16:29 -0400"; >>>> modification-date="Thu, 08 Oct 2015 13:17:29 -0400" >>>> Content-Transfer-Encoding: base64 >>>> >>>> >>>> >>>> >>>> >>>> - >>>> 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 -- Tim Pleiman http://support.bravosystemstech.net Bravo Systems Technologies "Advanced Open Source Solutions for Business" Chicago, IL USA **No trees were killed in the sending of this message, but a large number of electrons were terribly inconvenienced. - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Helping Out, e.g. >>Re: [qmailtoaster] RE: Shubes
Hi, I've been watching closely the developments with respect to the missing site personnel for Qmailtoaster. I keep copies of all regular list meesages from the toaster list for reference as needed and have gotten involved in the list from time to time, dating back to 2009. At one point I even offered Shubes to make a regular donation, but he was never able to identify how I could do that. I've got several qmail servers installed for my small business clients, and upgraded most of them late last year, when everything was still working. However, even then I was noting that everything was looking pretty old. I've been working with Qmail for over a decade, having come over to Qmailtoaster from Qmailrocks long ago. I have tended to pop in and out of paying attention over time, as all seemed to generally be under control. And, I just don't have issues with the toaster at all, so I get busy with other matters. But, these latest events are troublesome. At this point, in terms of where Eric Shubert is, has anyone been able to get in touch with him? This project, IMO, is too valuable to let fade. And, I'm willing to help out in any way I can. I do note that Vickers Consulting Group appears to be fully closed at this point, Jake having pursued setting up a photography business: http://jakev.com? Is there a way to get through to anyone so that full control of this project can be transferred into appropriate, capable hands? I'm not on the Qmail-devel list, where I suspect more is happening concerning this. Again, am willing to help out here. Again, very concerned. Please advise. And, how do I get on the devel list? Thanks, Tim Pleiman -- Tim Pleiman http://support.bravosystemstech.net Bravo Systems Technologies "Advanced Open Source Solutions for Business" Chicago, IL USA 773-852-4408 On Thu, September 17, 2015 3:36 pm, Dan McAllister wrote: > NOTE: I have not only sent emails, but I have also called on the > telephone to speak to Eric -- all to no avail. > > As hesitant as I am to "steal" a project from anyone, I am prepared to > move on redirecting the DNS to other servers that can be more actively > maintained. (Remember, I have control of the DNS servers -- at least as > defined at the registrar. So, so long as the entries at the registrar > still point to my servers, we have significant control over the domain). > > However, I think a more appropriate location to hold this discussion > would be the qmailtoaster-devel list (which I have copied). > > If you are on the qmailtoaster-devel mail list, please continue the > discussion there. > > Thanks > > Dan McAllister > IT4SOHO > QMT DNS/Mirror Admin > > > > > On 9/17/2015 10:23 AM, Edwin C wrote: >> >> In the spirit of volunteering, i can provide a vps to the community. >> I have hosting skills. >> >> I also do wordpress websites via my company www.filipinowebservices.com >> >> Let me know how i can help. >> >> On Sep 17, 2015 13:32, "L.A." <pc...@yandex.ru> wrote: >> Same here. >> Making copy of centos6 for local use now :( >> Looks like we need at least two leaders with all access, that will not >> disappear simultaneously. >> 10.09.2015, 01:32, "Havrla" <hav...@lhotkanet.cz>: >>> Hello >>> >>> I'm sorry my English is not good. >>> >>> I have QMT since 2003, actually 2015 - 2003 = 12 years. That's a long >>> time. >>> >>> I would be very unhappy if the project did not continue >>> >>> Website of the project seem dead. the only living thing is >>> email-list. I was so unhappy after new information on the >>> continuation and CentOS7, so I volunteered email-list. Information >>> gained and QMT on CentOS7 comfortably installed, without compiling, >>> without complications. I configured a pÅemigroval old QMT. It works. >>> I'm happy. >>> Plenty of other administrators would be happy if the project and >>> website relaunched and updated. >>> >>> I can provide mirror web hosting for the web. I fear the end of QMT >>> several years, so I have a backup >>> http://www.lhotkanet.cz/mirror/www.qmailtoaster.com/ >>> >>> Good luck finding Eric "Shubes", please choose a successor to >>> continue the project. I do not end up project. >>> >>> History "authors" from website QMT: >>> 2003 - first Miguel Beccari <mailto:miguel.becc...@clikka.com> - web >>> live >>> 2004 - Miguel Beccari <mailto:miguel.becc...@clikka.com> and Nick >>> Hemmesch <mailto:n...@ndhsoft.com> - web live >>> 2005 - Nick Hemmesch - web live <mailto:n...@ndhsoft.com> >
[qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files?
I now have a toaster server with multiple ip addresses bound to the WAN Nic. Qmail-smtpd automatically listens on both ip addresses inbound (eth0 and eth0:0), but by default qmail-remote binds to only the first (eth0) outbound. In a situation where eth0 is down (with only eth0:0 available), this causes qmail-remote to hold messages in queue until eth0 becomes available again. Are the following qmail control options available for qmail-remote--e.g. patched into the toaster distribution? If so, what would be the best configuration utilizing these control options--e.g. to always have qmail-remote bind to the IP address on eth0 when available, but to automatically fail to the IP address on eth0:0 when eth0 is not available? Or would I need a script to update one of these control files that executes automatically during a failover to the IP on eth0:0 when the IP on eth0 is not available? bindroutes (qmail-remote) Any mail sent from an specific source IP address will be sent from the given IP address. The entry in bindroutes looks like this: source ip:ip Example for bindroutes: # network 10.x.x.x 10.:1.2.3.4 # network 10.10.x.x 10.10.:1.2.3.4 # network 10.10.10.x 10.10.10.:1.2.3.4 # host 10.10.10.10 10.10.10.10:1.2.3.4 # rest :1.2.3.4 # don't send any mail to this 1.2.3.4: If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. senderip overwrites bindroutes. and/or senderip (qmail-remote) Any mail sent from an email address in the given domain will be sent from the given IP address. The entry in senderip looks like this: domain:ip If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
RE: [qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files?
eth0:0 is a child of the parent, eth0. If the physical interface itself dies, they both go down. You also cannot manually take down (ifdown interface) eth0 without also taking down eth0:0. They function together as eth0. However, when you have a multi-wan setup in this situation (which is a real life setup in this case), the interface is binding to two ip addresses with two different network routes. iproute2 routing entries are utilized to direct in/out traffic to the correct network gateway, depending on origination, and a failover script changes the default outbound gateway from the parent's to the child's if a particular server beyond the parent's gateway cannot be detected via the parent. This is not an issue with the actual interface going down, but with the route becoming unavailable on the parent (eth0) when the service provider's network goes down on the parent. What I've discovered is that Qmail remote natively binds to the ip address of the parent here unless otherwise instructed, disregarding the default outbound gateway no matter what. Hence the need for bindroutes or senderip, which I do believe can be utilized to solve my problem. So, the original question, I do believe, applies. There may be other solutions, e.g. additional routing entries placed in failover script as well to route traffic from one network to the other network, but either way, I need to get qmail traffic to go out the child interface ip address here instead of getting stuck in the queue on the parent interface ip address. bindroutes and/or senderip should work as one solution though, perhaps the simplest, unless I have to re-patch to use them. Thanks! Tim On Thu, October 6, 2011 2:52 pm, Michael J. Colvin wrote: Maybe I'm missing something, but other than administratively taking eth0 down, and leaving eth0:0 up, how would eth 0 go down and NOT take eth0:0 with it? IE, a cable being bad, or the switch port that patch cable is plugged into going bad, is going to take eth0 AND eth0:0 down. They're both part of the same physical port, no? Now, if you had eth0 and eth1, both different physical ports, with different physical connections, I could see what you're trying to accomplish... Two ip addresses doesn't necessarily mean two separate connections, just because you've bound them to a physical Ethernet interface and a virtual/sub interface... Mike -Original Message- From: Tim Pleiman [mailto:tplei...@bravosystemstech.net] Sent: Thursday, October 06, 2011 10:13 AM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files? I now have a toaster server with multiple ip addresses bound to the WAN Nic. Qmail-smtpd automatically listens on both ip addresses inbound (eth0 and eth0:0), but by default qmail-remote binds to only the first (eth0) outbound. In a situation where eth0 is down (with only eth0:0 available), this causes qmail-remote to hold messages in queue until eth0 becomes available again. Are the following qmail control options available for qmail-remote--e.g. patched into the toaster distribution? If so, what would be the best configuration utilizing these control options--e.g. to always have qmail-remote bind to the IP address on eth0 when available, but to automatically fail to the IP address on eth0:0 when eth0 is not available? Or would I need a script to update one of these control files that executes automatically during a failover to the IP on eth0:0 when the IP on eth0 is not available? bindroutes (qmail-remote) Any mail sent from an specific source IP address will be sent from the given IP address. The entry in bindroutes looks like this: source ip:ip Example for bindroutes: # network 10.x.x.x 10.:1.2.3.4 # network 10.10.x.x 10.10.:1.2.3.4 # network 10.10.10.x 10.10.10.:1.2.3.4 # host 10.10.10.10 10.10.10.10:1.2.3.4 # rest :1.2.3.4 # don't send any mail to this 1.2.3.4: If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. senderip overwrites bindroutes. and/or senderip (qmail-remote) Any mail sent from an email address in the given domain will be sent from the given IP address. The entry in senderip looks like this: domain:ip If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
RE: [qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files?
More... This question has actually been asked similarly before (in 2008), but not recently from what I can tell: http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg20024.html So, perhaps just an update answer as to whether I need to patch qmail-remote manually or whether these features are now included in the toaster. Any other suggestions also appreciated. Thanks! Tim On Thu, October 6, 2011 10:52 pm, Tim Pleiman wrote: eth0:0 is a child of the parent, eth0. If the physical interface itself dies, they both go down. You also cannot manually take down (ifdown interface) eth0 without also taking down eth0:0. They function together as eth0. However, when you have a multi-wan setup in this situation (which is a real life setup in this case), the interface is binding to two ip addresses with two different network routes. iproute2 routing entries are utilized to direct in/out traffic to the correct network gateway, depending on origination, and a failover script changes the default outbound gateway from the parent's to the child's if a particular server beyond the parent's gateway cannot be detected via the parent. This is not an issue with the actual interface going down, but with the route becoming unavailable on the parent (eth0) when the service provider's network goes down on the parent. What I've discovered is that Qmail remote natively binds to the ip address of the parent here unless otherwise instructed, disregarding the default outbound gateway no matter what. Hence the need for bindroutes or senderip, which I do believe can be utilized to solve my problem. So, the original question, I do believe, applies. There may be other solutions, e.g. additional routing entries placed in failover script as well to route traffic from one network to the other network, but either way, I need to get qmail traffic to go out the child interface ip address here instead of getting stuck in the queue on the parent interface ip address. bindroutes and/or senderip should work as one solution though, perhaps the simplest, unless I have to re-patch to use them. Thanks! Tim On Thu, October 6, 2011 2:52 pm, Michael J. Colvin wrote: Maybe I'm missing something, but other than administratively taking eth0 down, and leaving eth0:0 up, how would eth 0 go down and NOT take eth0:0 with it? IE, a cable being bad, or the switch port that patch cable is plugged into going bad, is going to take eth0 AND eth0:0 down. They're both part of the same physical port, no? Now, if you had eth0 and eth1, both different physical ports, with different physical connections, I could see what you're trying to accomplish... Two ip addresses doesn't necessarily mean two separate connections, just because you've bound them to a physical Ethernet interface and a virtual/sub interface... Mike -Original Message- From: Tim Pleiman [mailto:tplei...@bravosystemstech.net] Sent: Thursday, October 06, 2011 10:13 AM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files? I now have a toaster server with multiple ip addresses bound to the WAN Nic. Qmail-smtpd automatically listens on both ip addresses inbound (eth0 and eth0:0), but by default qmail-remote binds to only the first (eth0) outbound. In a situation where eth0 is down (with only eth0:0 available), this causes qmail-remote to hold messages in queue until eth0 becomes available again. Are the following qmail control options available for qmail-remote--e.g. patched into the toaster distribution? If so, what would be the best configuration utilizing these control options--e.g. to always have qmail-remote bind to the IP address on eth0 when available, but to automatically fail to the IP address on eth0:0 when eth0 is not available? Or would I need a script to update one of these control files that executes automatically during a failover to the IP on eth0:0 when the IP on eth0 is not available? bindroutes (qmail-remote) Any mail sent from an specific source IP address will be sent from the given IP address. The entry in bindroutes looks like this: source ip:ip Example for bindroutes: # network 10.x.x.x 10.:1.2.3.4 # network 10.10.x.x 10.10.:1.2.3.4 # network 10.10.10.x 10.10.10.:1.2.3.4 # host 10.10.10.10 10.10.10.10:1.2.3.4 # rest :1.2.3.4 # don't send any mail to this 1.2.3.4: If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. senderip overwrites bindroutes. and/or senderip (qmail-remote) Any mail sent from an email address in the given domain will be sent from the given IP address. The entry in senderip looks like this: domain:ip If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. -- Tim Pleiman Bravo Systems
[qmailtoaster] Qmail control smtphosts...is this true?
To anyone who might know, I find various online references to a qmail control file: /var/qmail/control/smtphosts that is not generally used in all qmail installations, whereby: If the file /var/qmail/control/smtphosts exists and contains an entry for hisdomain.com, qmail will not perform a DNS MX-lookup to figure out the mail server for hisdomain.com; it will use the one specified there, such as: .hisdomain.com:pop2.hisdomain.com Otherwise, qmail will perform a DNS/MX lookup. The reason I ask has to do with something I mentioned earlier concerning mail client lookups of mx records returning 451--DNS temporary failure and stubbornly refusing to place such messages in the queue even though I know the message will be delivered. I'm having periodic trouble with a couple of Chinese DNS mx lookups (as they fool around with their DNS servers over there), and if the above is working in qmailtoaster, then that will alleviate this problem on specific domains entirely without having to disable the CHKUSER feature that prevents such messages from being queued. Thanks! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Re: Qmail control smtphosts...is this true?
Yes, the smtphosts file seems to be some sort of mistake that's published in places. So then with smtproutes, it can serve two purposes: 1. To relay all outbound mail through a trusted host, via: :mail.somedomain.com or 2. To relay/send selected mail to a specific domain, bypassing an MX lookup via: somedomain.com:mx-static-record-for-somedomain.com Correct? Just wanting to confirm because I've never needed to use the second option. Thanks, Tim On Thu, September 29, 2011 11:58 am, Eric Shubert wrote: On 09/29/2011 09:48 AM, Tim Pleiman wrote: To anyone who might know, I find various online references to a qmail control file: /var/qmail/control/smtphosts that is not generally used in all qmail installations, whereby: If the file /var/qmail/control/smtphosts exists and contains an entry for hisdomain.com, qmail will not perform a DNS MX-lookup to figure out the mail server for hisdomain.com; it will use the one specified there, such as: .hisdomain.com:pop2.hisdomain.com Otherwise, qmail will perform a DNS/MX lookup. The reason I ask has to do with something I mentioned earlier concerning mail client lookups of mx records returning 451--DNS temporary failure and stubbornly refusing to place such messages in the queue even though I know the message will be delivered. I'm having periodic trouble with a couple of Chinese DNS mx lookups (as they fool around with their DNS servers over there), and if the above is working in qmailtoaster, then that will alleviate this problem on specific domains entirely without having to disable the CHKUSER feature that prevents such messages from being queued. Thanks! Tim This sounds like the /var/qmail/control/smtproutes file in QMT: http://wiki.qmailtoaster.com/index.php/Smtproutes -- -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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER
Eric, Over the last couple of years working with qmailtoaster, I've come to both love and hate this particular CHKUSER check. I keep copies of all the messages from the qmt list, and searching for the string 451 DNS Temporary Problem, it seems to me that people have many problems with it that could be addressed with some simple fixes to the CHKUSR code--e.g. more detailed error responses from CHKUSER that better define the nature of the problem. Unlike the posts I've read over the last year or so, I'm not having any trouble with my caching nameserver, DJBDNS. It's working properly, has always been working properly. I love DJBDNS. However, here's the problem that I have with this particular CHKUSER check: When a sender tries to send a message to a single u...@domain.com, if the domain MX is unresolveable in DNS as follows: 2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output error CHKUSR will return the 451 DNS Temporary Failure error indicative of the issue. In this case today, the above particular domain has no MX record for it's e-mail--their problem, not mine. So, this immediately prevents queuing of messages in QMail that cannot currently be delivered immediately to that one particular domain. This is a good thing as it alerts the sender that the message cannot be delivered now--e.g. QMail is not going to queue the message now because it would just sit there, either waiting for the MX to become available or, if it does not, bouncing the message after the queuelifetime expires. Now, aside from the fact that the average person doesn't know what this means, I can deal with it, albeit it is not ideal (the average user-sender does not know what the heck 451 DNS Temporary Failure is). However, when sending out a multi-recipient message, this is when the issue gets really dicey. CHKUSR stubbornly refuses to queue the message at all for any of the recipients, even the ones that have valid MXes, as it simply also returns the 451 DNS Temporary Failure error with no other information at all. What this means is that the sender of the multi-recipient message has to figure out on his/her own which e-mail domain can currently not accept a delivery. The only way to determine this is to send the message to each of the recipients individually until you hit the one with the invalid/unavailable MX. Now, I think the ultimate resolution of this issue would be for CHKUSER to be updated to provide better error responses on this particular check. For single-recipient messages, it should respond with something like 451 DNS temporary failure: mail server for domain 'somedomain.com' is currently unavailable. In the case of multi-recipient messages, it should go ahead and queue the message for the valid domains, while returning a similar error for the MX domain(s) that is not available. Meanwhile, from what I can tell from the list archives, there is currently no way to disable this CHKUSER check entirely without manually recompiling CHKUSER. If there is already a simple fix/adjustment for this, let me know (and I'll apologize in advance for missing this). Otherwise, it would be great in future QMT releases to have this CHKUSER check disabled entirely, pending an adjustment to CHKUSER, as it results in lots of puzzled user inquiries. With this disabled, such messages would go into the queue for QMail to bounce on its own. I understand that the feature also alerts admins to their own DNS server issues as well. However, those should be issues that server admins can resolve on their own anyway. It's the user-related problems that this check causes that, to me, are most troublesome. Thanks! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] Updated more info[Fwd: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER]
Here's the troublesome feature: CHKUSER_RCPTMX_TMP_STRING 2.0.7 defined 451 DNS temporary failure (#4.5.1 - chkuser)\r\n String emitted if there is a soft DNS error on recipient domain. Original Message Subject: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER From:Tim Pleiman tplei...@bravosystemstech.net Date:Wed, August 31, 2011 2:00 pm To: qmailtoaster-list@qmailtoaster.com -- Eric, Over the last couple of years working with qmailtoaster, I've come to both love and hate this particular CHKUSER check. I keep copies of all the messages from the qmt list, and searching for the string 451 DNS Temporary Problem, it seems to me that people have many problems with it that could be addressed with some simple fixes to the CHKUSR code--e.g. more detailed error responses from CHKUSER that better define the nature of the problem. Unlike the posts I've read over the last year or so, I'm not having any trouble with my caching nameserver, DJBDNS. It's working properly, has always been working properly. I love DJBDNS. However, here's the problem that I have with this particular CHKUSER check: When a sender tries to send a message to a single u...@domain.com, if the domain MX is unresolveable in DNS as follows: 2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output error CHKUSR will return the 451 DNS Temporary Failure error indicative of the issue. In this case today, the above particular domain has no MX record for it's e-mail--their problem, not mine. So, this immediately prevents queuing of messages in QMail that cannot currently be delivered immediately to that one particular domain. This is a good thing as it alerts the sender that the message cannot be delivered now--e.g. QMail is not going to queue the message now because it would just sit there, either waiting for the MX to become available or, if it does not, bouncing the message after the queuelifetime expires. Now, aside from the fact that the average person doesn't know what this means, I can deal with it, albeit it is not ideal (the average user-sender does not know what the heck 451 DNS Temporary Failure is). However, when sending out a multi-recipient message, this is when the issue gets really dicey. CHKUSR stubbornly refuses to queue the message at all for any of the recipients, even the ones that have valid MXes, as it simply also returns the 451 DNS Temporary Failure error with no other information at all. What this means is that the sender of the multi-recipient message has to figure out on his/her own which e-mail domain can currently not accept a delivery. The only way to determine this is to send the message to each of the recipients individually until you hit the one with the invalid/unavailable MX. Now, I think the ultimate resolution of this issue would be for CHKUSER to be updated to provide better error responses on this particular check. For single-recipient messages, it should respond with something like 451 DNS temporary failure: mail server for domain 'somedomain.com' is currently unavailable. In the case of multi-recipient messages, it should go ahead and queue the message for the valid domains, while returning a similar error for the MX domain(s) that is not available. Meanwhile, from what I can tell from the list archives, there is currently no way to disable this CHKUSER check entirely without manually recompiling CHKUSER. If there is already a simple fix/adjustment for this, let me know (and I'll apologize in advance for missing this). Otherwise, it would be great in future QMT releases to have this CHKUSER check disabled entirely, pending an adjustment to CHKUSER, as it results in lots of puzzled user inquiries. With this disabled, such messages would go into the queue for QMail to bounce on its own. I understand that the feature also alerts admins to their own DNS server issues as well. However, those should be issues that server admins can resolve on their own anyway. It's the user-related problems that this check causes that, to me, are most troublesome. Thanks! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim
Re: [qmailtoaster] Re: Updated more info[Fwd: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER]
Is that this tcp.smtp rule? SENDER_NOCHECK=1 It's possible that I may have dealt with this before on a different server and have simply forgotten. I implemented the above setting on another system due to some other similar issue as I recall. I'm thinking that the above disables a bunch of different MX checks by CHKUSER, possibly including this one. However, is this the more specific rule? CHKUSER_RCPT_MX=0 I can't seem to find a list over at interazioni.it for all the tcp.smtp rule settings. These servers are all at CHKUSER 2.0.8, so I'm thinking I should be able to turn this off then in tcp.smtp provided I choose the right rule setting. However, in 2.0.8, according to interazioni.it, the CHKUSER_RCPT_MX setting is undefined which should mean that it's off by default, correct? So, that's confusing me as to why the check is happening at all. Ideas? Thanks, Tim On Wed, August 31, 2011 3:42 pm, Eric Shubert wrote: I believe that the default chkuser settings will be used in QMTv2. According to http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html the MX checks are now off by default. I believe that they can be turned on with an environment variable set in the tcp.smtp or run file if desired, so no rebuilding will be needed. On 08/31/2011 12:19 PM, Tim Pleiman wrote: Here's the troublesome feature: CHKUSER_RCPTMX_TMP_STRING2.0.7 defined 451 DNS temporary failure (#4.5.1 - chkuser)\r\n String emitted if there is a soft DNS error on recipient domain. Original Message Subject: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER From:Tim Pleimantplei...@bravosystemstech.net Date:Wed, August 31, 2011 2:00 pm To: qmailtoaster-list@qmailtoaster.com -- Eric, Over the last couple of years working with qmailtoaster, I've come to both love and hate this particular CHKUSER check. I keep copies of all the messages from the qmt list, and searching for the string 451 DNS Temporary Problem, it seems to me that people have many problems with it that could be addressed with some simple fixes to the CHKUSR code--e.g. more detailed error responses from CHKUSER that better define the nature of the problem. Unlike the posts I've read over the last year or so, I'm not having any trouble with my caching nameserver, DJBDNS. It's working properly, has always been working properly. I love DJBDNS. However, here's the problem that I have with this particular CHKUSER check: When a sender tries to send a message to a single u...@domain.com, if the domain MX is unresolveable in DNS as follows: 2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output error CHKUSR will return the 451 DNS Temporary Failure error indicative of the issue. In this case today, the above particular domain has no MX record for it's e-mail--their problem, not mine. So, this immediately prevents queuing of messages in QMail that cannot currently be delivered immediately to that one particular domain. This is a good thing as it alerts the sender that the message cannot be delivered now--e.g. QMail is not going to queue the message now because it would just sit there, either waiting for the MX to become available or, if it does not, bouncing the message after the queuelifetime expires. Now, aside from the fact that the average person doesn't know what this means, I can deal with it, albeit it is not ideal (the average user-sender does not know what the heck 451 DNS Temporary Failure is). However, when sending out a multi-recipient message, this is when the issue gets really dicey. CHKUSR stubbornly refuses to queue the message at all for any of the recipients, even the ones that have valid MXes, as it simply also returns the 451 DNS Temporary Failure error with no other information at all. What this means is that the sender of the multi-recipient message has to figure out on his/her own which e-mail domain can currently not accept a delivery. The only way to determine this is to send the message to each of the recipients individually until you hit the one with the invalid/unavailable MX. Now, I think the ultimate resolution of this issue would be for CHKUSER to be updated to provide better error responses on this particular check. For single-recipient messages, it should respond with something like 451 DNS temporary failure: mail server for domain 'somedomain.com' is currently unavailable. In the case of multi-recipient messages, it should go ahead and queue the message for the valid domains, while returning a similar error for the MX domain(s) that is not available. Meanwhile, from what I can tell from the list archives, there is currently no way to disable this CHKUSER check entirely without manually recompiling CHKUSER
[qmailtoaster] OK, I think I get youRe: [qmailtoaster] Re: Updated more info[Fwd: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER]
So, what you're saying is that all of these: CHKUSER_RCPT_FORMAT CHKUSER_RCPT_MX CHKUSER_SENDER_FORMAT CHKUSER_SENDER_MX are still set active during the default QMT installation even though 2.0.8 of CHKUSER is present in current QMT installs and 2.0.8 of CHKUSER is supposed to have them already off by default? So then, the above are going to be default disabled in QMTv2? And there will be the ability to change an environment variable setting in tcp.smtp to turn these on individually as desired in QMTv2? Let me know if I've got that right. ;) Thanks! Tim On Wed, August 31, 2011 3:42 pm, Eric Shubert wrote: I believe that the default chkuser settings will be used in QMTv2. According to http://www.interazioni.it/opensource/chkuser/documentation/chkuser_settings.html the MX checks are now off by default. I believe that they can be turned on with an environment variable set in the tcp.smtp or run file if desired, so no rebuilding will be needed. On 08/31/2011 12:19 PM, Tim Pleiman wrote: Here's the troublesome feature: CHKUSER_RCPTMX_TMP_STRING2.0.7 defined 451 DNS temporary failure (#4.5.1 - chkuser)\r\n String emitted if there is a soft DNS error on recipient domain. Original Message Subject: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER From:Tim Pleimantplei...@bravosystemstech.net Date:Wed, August 31, 2011 2:00 pm To: qmailtoaster-list@qmailtoaster.com -- Eric, Over the last couple of years working with qmailtoaster, I've come to both love and hate this particular CHKUSER check. I keep copies of all the messages from the qmt list, and searching for the string 451 DNS Temporary Problem, it seems to me that people have many problems with it that could be addressed with some simple fixes to the CHKUSR code--e.g. more detailed error responses from CHKUSER that better define the nature of the problem. Unlike the posts I've read over the last year or so, I'm not having any trouble with my caching nameserver, DJBDNS. It's working properly, has always been working properly. I love DJBDNS. However, here's the problem that I have with this particular CHKUSER check: When a sender tries to send a message to a single u...@domain.com, if the domain MX is unresolveable in DNS as follows: 2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output error CHKUSR will return the 451 DNS Temporary Failure error indicative of the issue. In this case today, the above particular domain has no MX record for it's e-mail--their problem, not mine. So, this immediately prevents queuing of messages in QMail that cannot currently be delivered immediately to that one particular domain. This is a good thing as it alerts the sender that the message cannot be delivered now--e.g. QMail is not going to queue the message now because it would just sit there, either waiting for the MX to become available or, if it does not, bouncing the message after the queuelifetime expires. Now, aside from the fact that the average person doesn't know what this means, I can deal with it, albeit it is not ideal (the average user-sender does not know what the heck 451 DNS Temporary Failure is). However, when sending out a multi-recipient message, this is when the issue gets really dicey. CHKUSR stubbornly refuses to queue the message at all for any of the recipients, even the ones that have valid MXes, as it simply also returns the 451 DNS Temporary Failure error with no other information at all. What this means is that the sender of the multi-recipient message has to figure out on his/her own which e-mail domain can currently not accept a delivery. The only way to determine this is to send the message to each of the recipients individually until you hit the one with the invalid/unavailable MX. Now, I think the ultimate resolution of this issue would be for CHKUSER to be updated to provide better error responses on this particular check. For single-recipient messages, it should respond with something like 451 DNS temporary failure: mail server for domain 'somedomain.com' is currently unavailable. In the case of multi-recipient messages, it should go ahead and queue the message for the valid domains, while returning a similar error for the MX domain(s) that is not available. Meanwhile, from what I can tell from the list archives, there is currently no way to disable this CHKUSER check entirely without manually recompiling CHKUSER. If there is already a simple fix/adjustment for this, let me know (and I'll apologize in advance for missing this). Otherwise, it would be great in future QMT releases to have this CHKUSER check disabled entirely, pending an adjustment to CHKUSER, as it results in lots of puzzled user inquiries
Re: [qmailtoaster] 451 DNS Temporary Failure: Issue that should be addressed in CHKUSER
* 2.0.9 undefined CHKUSER_MUSTAUTH for having a server accepting only authenticated users (any port or submission port). For version 2.0.8 you may use (recompiling) both: *CHKUSER_SENDER_NOCHECK_VARIABLE *2.0.5 commented SENDER_NOCHECK *CHKUSER_STARTING_VARIABLE* 2.0.5 commented CHKUSER_START Playing with those settings, you may enable or disable chkuser accordingly to variable settings. For such scopes, I sugges not to put variables inside tcp.smtp, but directly within running command, because behaviour is per server and not per IP. Regards, Tonino Il 31/08/2011 21:00, Tim Pleiman ha scritto: Eric, Over the last couple of years working with qmailtoaster, I've come to both love and hate this particular CHKUSER check. I keep copies of all the messages from the qmt list, and searching for the string 451 DNS Temporary Problem, it seems to me that people have many problems with it that could be addressed with some simple fixes to the CHKUSR code--e.g. more detailed error responses from CHKUSER that better define the nature of the problem. Unlike the posts I've read over the last year or so, I'm not having any trouble with my caching nameserver, DJBDNS. It's working properly, has always been working properly. I love DJBDNS. However, here's the problem that I have with this particular CHKUSER check: When a sender tries to send a message to a single u...@domain.com, if the domain MX is unresolveable in DNS as follows: 2011-08-31 12:56:25.14400 servfail nc-mail.nchicago.org. input/output error CHKUSR will return the 451 DNS Temporary Failure error indicative of the issue. In this case today, the above particular domain has no MX record for it's e-mail--their problem, not mine. So, this immediately prevents queuing of messages in QMail that cannot currently be delivered immediately to that one particular domain. This is a good thing as it alerts the sender that the message cannot be delivered now--e.g. QMail is not going to queue the message now because it would just sit there, either waiting for the MX to become available or, if it does not, bouncing the message after the queuelifetime expires. Now, aside from the fact that the average person doesn't know what this means, I can deal with it, albeit it is not ideal (the average user-sender does not know what the heck 451 DNS Temporary Failure is). However, when sending out a multi-recipient message, this is when the issue gets really dicey. CHKUSR stubbornly refuses to queue the message at all for any of the recipients, even the ones that have valid MXes, as it simply also returns the 451 DNS Temporary Failure error with no other information at all. What this means is that the sender of the multi-recipient message has to figure out on his/her own which e-mail domain can currently not accept a delivery. The only way to determine this is to send the message to each of the recipients individually until you hit the one with the invalid/unavailable MX. Now, I think the ultimate resolution of this issue would be for CHKUSER to be updated to provide better error responses on this particular check. For single-recipient messages, it should respond with something like 451 DNS temporary failure: mail server for domain 'somedomain.com' is currently unavailable. In the case of multi-recipient messages, it should go ahead and queue the message for the valid domains, while returning a similar error for the MX domain(s) that is not available. Meanwhile, from what I can tell from the list archives, there is currently no way to disable this CHKUSER check entirely without manually recompiling CHKUSER. If there is already a simple fix/adjustment for this, let me know (and I'll apologize in advance for missing this). Otherwise, it would be great in future QMT releases to have this CHKUSER check disabled entirely, pending an adjustment to CHKUSER, as it results in lots of puzzled user inquiries. With this disabled, such messages would go into the queue for QMail to bounce on its own. I understand that the feature also alerts admins to their own DNS server issues as well. However, those should be issues that server admins can resolve on their own anyway. It's the user-related problems that this check causes that, to me, are most troublesome. Thanks! Tim -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations
[qmailtoaster] qmail-remote/qmail-smtpd and multiple WAN IP addresses on same box
I'm in the process of upgrading a system with load balacing/failover from 2 different ISPs on a single box, e.g.: http://www.xenocafe.com/tutorials/linux/redhat/bind_multiple_ip_addresses_to_single_nic/index.php What I wish to be able to do is have qmail-smtpd listening on both IP addresses for inbound mail traffic at all times. Then have qmail-remote select the first available address to send outbound traffic--e.g. either IP that is available, so that if one goes down, qmail-remote will automatically determine to send on the other. Is this possible with the current qmailtoaster distribution? I've seen posts in other forums with similar questions, some indicate that a patch is required or to have the services bound to specific IPs. None of the information I can find gives information specific as to what I'm trying to accomplish. Many thanks in advance! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] qmail-remote/qmail-smtpd and multiple WAN IP addresses on same box
Thanks Dan, Thanks for confirming what would occur with outbound mail. However, what about inbound mail, whereby one connection handles mail for mx mail1..com and another for mail2..com? Will tcpserver/qmail-smtpd open whatever connections it needs there as well?: vpopmail 2706 0.0 0.0 3824 416 ?SJul01 0:00 /usr/bin/tcpserver -v -R -H -l mail.dmsystems.com -x /etc/tcprules.d/tcp.smtp.cdb -c 100 -u 89 -g 89 0 587 /var/qmail/bin/qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true tcp0 0 xx.xxx.xxx.xxx:25 74.84.128.73:47345 ESTABLISHED tcp0 0 xx.xxx.xxx.xxx:25 69.199.67.164:4478 TIME_WAIT Obviously it opens multiple listening connections on the same single IP as indicated above. Thanks, Tim On Thu, July 14, 2011 11:20 am, Dan McAllister wrote: Tim, I think your problem is different from what you've read on the other forums... specifically, I suspect that they wanted to have the system attached to both IP addresses (both ISPs), but have QMail use only one THAT requires a patch. What you're proposing is that you have 2 IP addresses (whether on a pair (or more) of NICs, or shared on one NIC won't matter) and that you let whatever internal load balancing is in effect control the outbound message flow. This is the DEFAULT behavior of QMail, so no patches are necessary. One brief caveat -- if you're using SPF, make sure BOTH of your public IP addresses are valid -- and make sure BOTH of your public IP addresses have appropriate reverse-DNS entries. Good Luck! Dan IT4SOHO On 7/14/2011 11:31 AM, Tim Pleiman wrote: I'm in the process of upgrading a system with load balacing/failover from 2 different ISPs on a single box, e.g.: http://www.xenocafe.com/tutorials/linux/redhat/bind_multiple_ip_addresses_to_single_nic/index.php What I wish to be able to do is have qmail-smtpd listening on both IP addresses for inbound mail traffic at all times. Then have qmail-remote select the first available address to send outbound traffic--e.g. either IP that is available, so that if one goes down, qmail-remote will automatically determine to send on the other. Is this possible with the current qmailtoaster distribution? I've seen posts in other forums with similar questions, some indicate that a patch is required or to have the services bound to specific IPs. None of the information I can find gives information specific as to what I'm trying to accomplish. Many thanks in advance! Tim - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] SpamdykeFalse DENIED_SENDER_NO_MX error?
It appears that I may be, at least on occasion, having the following problem that Eric discovered here: http://comments.gmane.org/gmane.mail.spam.spamdyke.user/3106 Today it is affecting google's gmail servers: 2011-04-28 12:23:13.290273500 spamdyke[11358]: ERROR: DNS response for adaxa.com: expected type MX, A, CNAME but received type (unknown) 2011-04-28 12:23:13.290860500 spamdyke[11358]: FILTER_SENDER_NO_MX domain: adaxa.com 2011-04-28 12:23:13.826486500 spamdyke[11358]: DENIED_SENDER_NO_MX from: ...@adaxa.com to: ...@bravosystemstech.net origin_ip: 209.85.212.43 origin_rdns: mail-vw0-f43.google.com auth: (unknown) encryption: TLS 2011-04-28 12:24:15.335562500 spamdyke[11358]: TIMEOUT from: ...@adaxa.com to: ...@bravosystemstech.net origin_ip: 209.85.212.43 origin_rdns: mail-vw0-f43.google.com auth: (unknown) encryption: TLS reason: TIMEOUT On the particular server that's having this trouble, I'm running spamdyke 4.1.0. It appears from the above that this trouble was discovered after the release of the current 4.2.0 version (release Feb 11) of spamdyke. Does anyone know if this also affects version 4.1.0, and if so, how to bypass this without compromising security until a corrective update is released? It's definitely not affecting the 4.0.10 version of spamdyke that I have running on another qmailtoaster server as the mx lookups for the above domain are having no trouble there. Thanks, -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Re: SpamdykeFalse DENIED_SENDER_NO_MX error?
On Thu, April 28, 2011 3:43 pm, Eric Shubert wrote: On 04/28/2011 11:26 AM, Tim Pleiman wrote: It appears that I may be, at least on occasion, having the following problem that Eric discovered here: http://comments.gmane.org/gmane.mail.spam.spamdyke.user/3106 Today it is affecting google's gmail servers: 2011-04-28 12:23:13.290273500 spamdyke[11358]: ERROR: DNS response for adaxa.com: expected type MX, A, CNAME but received type (unknown) 2011-04-28 12:23:13.290860500 spamdyke[11358]: FILTER_SENDER_NO_MX domain: adaxa.com 2011-04-28 12:23:13.826486500 spamdyke[11358]: DENIED_SENDER_NO_MX from: ...@adaxa.com to: ...@bravosystemstech.net origin_ip: 209.85.212.43 origin_rdns: mail-vw0-f43.google.com auth: (unknown) encryption: TLS 2011-04-28 12:24:15.335562500 spamdyke[11358]: TIMEOUT from: ...@adaxa.com to: ...@bravosystemstech.net origin_ip: 209.85.212.43 origin_rdns: mail-vw0-f43.google.com auth: (unknown) encryption: TLS reason: TIMEOUT On the particular server that's having this trouble, I'm running spamdyke 4.1.0. It appears from the above that this trouble was discovered after the release of the current 4.2.0 version (release Feb 11) of spamdyke. Does anyone know if this also affects version 4.1.0, and if so, how to bypass this without compromising security until a corrective update is released? It's definitely not affecting the 4.0.10 version of spamdyke that I have running on another qmailtoaster server as the mx lookups for the above domain are having no trouble there. Thanks, I've commented out that rule for the time being. I think that chkuser checks this as well, so it's not really a concern. -- -Eric 'shubes' Eric, Yes, I did that on the server running Spamdyke 4.1.0, and then I started getting the error only on gmail multihomed mx hosts (probably others too, although I saw them only from gmail connections while tailing the log): spamdyke[28535]: ERROR: unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found There was supposedly a fix in 4.1.0 to correct for the above message NOT being generated in the logs: http://permalink.gmane.org/gmane.mail.spam.spamdyke.user/2918 Now, since my server platforms are all the same, I reverted the 4.1.0 binary on this particular server to 4.0.10 (copied from another server) with reject-missing-sender-mx enabled, and then the process does seem to properly resolve these mxes, and also does seem to exit fine on it's own, despite what's indicated above. Hard to tell, as there is delay in the process exiting, which may indicate that there is an error message not being displayed. At any rate, it seems that there are multiple overlapping problems with the both the 4.2.0 and 4.1.0 releases that may also be dependent on what features one has turned on or off, although I can't quite pin down exactly what's going on. Hopefully this will all get cleared up in the next release. Will stick with 4.0.10 for now. Thanks! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
RE: [qmailtoaster] SpamAssassin Y2K10 bug
The offending rule: FH_DATE_PAST_20XX is in: /usr/share/spamassassin/72_active.cf and is scored by: /usr/share/spamassassin/50_scores.cf I would just remove the the rules and scores in these files, in addition to modifying your local.cf file to prevent future incarnations. There is some bit of controversy as to the rule existing at all and the fact that even though it was supposedly corrected 5 months ago, it was not pushed out to the installations or most update processes. Based on the fact that it wasn't killed ages ago, who knows whether or not it'll slip back in again? Tim On Mon, January 4, 2010 12:50 am, Helmut Fritz wrote: What was the offending rule, and was it removed by the update or just changed? I ran sa-update, but am not sure what it changed. Thx. Helmut -Original Message- From: Lucian Cristian [mailto:l...@createc.ro] Sent: Sunday, January 03, 2010 10:36 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] SpamAssassin Y2K10 bug Jake Vickers wrote: Eric Shubert wrote: This was posted this afternoon on the vpopmail list: Tom Collins wrote: If you're running SpamAssassin, be aware that it has a rule that's adding points to all mail with a 2010 date. You can fix it by adding the following to your local.cf and restarting spamassassin. scoreFH_DATE_PAST_20XX0.0 See https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 for details. -Tom Can we perhaps come up with a better fix? In the meantime, I'd suggest making this change, then running # qmail-spam restart Thanks for posting that Eric. I didn't see the announcement until today - I actually saw your post first. Anyway, as an FYI, updating your rules via sa-update should resolve this (can anyone confirm?): Subject: Apache SpamAssassin Y2K10 Rule Bug - Update Your Rules Now! From: Daryl C. W. O'Shea spamassas...@dostech.ca Date: Sat, 02 Jan 2010 02:38:13 -0500 I've posted the following note on the Apache SpamAssassin website [1] about an issue with a rule that may cause wanted email to be classified as spam by SpamAssassin. If you're running SpamAssassin 3.2.x you are encouraged to update you rules (updates were released on sa-update around 1900 UTC Jan 1, 2010). Y2K10 Rule Bug - Update Your Rules Now! -- --- 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 sa-update should work, for me it did Happy new year ! Lucian - 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 - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] The Brilliant SA Y210K bugfix...NOT!
This is the fix that was pushed out...
From this:
##{ FH_DATE_PAST_20XX
header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX
To this:
##{ FH_DATE_PAST_20XX
header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX
It's a very badly written rule.
Tim
--
Tim Pleiman
Bravo Systems Technologies
Advanced Open Source Solutions for Business
Chicago, IL USA
-
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
[qmailtoaster] Thank You!
Jake, Eric, I just want to offer a big round of thanks for such an excellent Qmail compilation. I've got it up and running now on two production servers and it has been flawless. Also, Jake, is there a not-for-profit Open Source project that you would like me to donate to on your behalf? As a measure of my gratitude for the excellence of compiling and maintaining this qmail distribution, I would like to send a donation to them. My consulting practice services many non-profit organizations at discount as well as donated capacities, so I like to support those things which do good for community. Contact me directly, please. Aditionally, is the EZMLM digest option for this list turned on? I'm finding it difficult to keep up with all the individual e-mail posts in my inbox. Thanks! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] Spamdyke logging with QMT integration
Hi all, Presumably, if I want to capture a spamdyke log, I would modify the following in the /var/run/qmail/supervise/run file (which with spamdyke installed with QMT is a symlink to run.spamdyke, so I would modify run.spamdyke): SPAMDYKE=/usr/local/bin/spamdyke to be SPAMDYKE=/usr/local/bin/spamdyke -lverbose or SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose Is this correct? If so, where do the logs go? Do they go to a default location? Or must that be specified? If it must be specified, is the log location to be added after -lverbose or --log-level=verbose as in: SPAMDYKE=/usr/local/bin/spamdyke -lverbose /var/log/spamdyke.log I'm not clear from the documentation at spamdyke.org as they simply indicate the following: /usr/local/bin/spamdyke --log-level=verbose ... The 3 dots being something that I'm not clear on as to what else should be placed there. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Spamdyke logging with QMT integration
Actually, I missed it. It's earlier in the documentation at spamdyke.org where the logs typically go: When spamdyke logs to syslog, it uses the LOG_MAIL facility, which typically puts the messages in /var/log/maillog. So, presuming this is true, so I presume that adding the logging options to the SPAMDYKE line in run.spamdyke file will then log spamdyke messages to /var/log/maillog? Everything correct? Will try. Thanks, Tim On Mon, July 27, 2009 11:35 am, Tim Pleiman wrote: Hi all, Presumably, if I want to capture a spamdyke log, I would modify the following in the /var/run/qmail/supervise/run file (which with spamdyke installed with QMT is a symlink to run.spamdyke, so I would modify run.spamdyke): SPAMDYKE=/usr/local/bin/spamdyke to be SPAMDYKE=/usr/local/bin/spamdyke -lverbose or SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose Is this correct? If so, where do the logs go? Do they go to a default location? Or must that be specified? If it must be specified, is the log location to be added after -lverbose or --log-level=verbose as in: SPAMDYKE=/usr/local/bin/spamdyke -lverbose /var/log/spamdyke.log I'm not clear from the documentation at spamdyke.org as they simply indicate the following: /usr/local/bin/spamdyke --log-level=verbose ... The 3 dots being something that I'm not clear on as to what else should be placed there. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] Does not default to maillog Re: [qmailtoaster] Spamdyke logging with QMT integration
Ok, So, tested and cannot get spamdyke logs to work (or they're going some other place that I can't find or into nothing): SPAMDYKE=/usr/local/bin/spamdyke -lverbose SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose SPAMDYKE=/usr/local/bin/spamdyke -ldebug SPAMDYKE=/usr/local/bin/spamdyke --log-level=debug Should be going into maillog as the default. Must be something I'm missing. Must something be done differently/peculiar to the QMT integration to get these logs? There are spamdyke entries being captured in the /var/log/qmail/send/current file, but no matter what I do with the loglevel specifcation on the spamdyke line, it doesn't output them to maillog on its own and it doesn't increase the level of logging in /var/log/qmail/send/current Would like to get those more detailed logs from spamdyke. Any ideas? Thanks, Tim On Mon, July 27, 2009 11:55 am, Tim Pleiman wrote: Actually, I missed it. It's earlier in the documentation at spamdyke.org where the logs typically go: When spamdyke logs to syslog, it uses the LOG_MAIL facility, which typically puts the messages in /var/log/maillog. So, presuming this is true, so I presume that adding the logging options to the SPAMDYKE line in run.spamdyke file will then log spamdyke messages to /var/log/maillog? Everything correct? Will try. Thanks, Tim On Mon, July 27, 2009 11:35 am, Tim Pleiman wrote: Hi all, Presumably, if I want to capture a spamdyke log, I would modify the following in the /var/run/qmail/supervise/run file (which with spamdyke installed with QMT is a symlink to run.spamdyke, so I would modify run.spamdyke): SPAMDYKE=/usr/local/bin/spamdyke to be SPAMDYKE=/usr/local/bin/spamdyke -lverbose or SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose Is this correct? If so, where do the logs go? Do they go to a default location? Or must that be specified? If it must be specified, is the log location to be added after -lverbose or --log-level=verbose as in: SPAMDYKE=/usr/local/bin/spamdyke -lverbose /var/log/spamdyke.log I'm not clear from the documentation at spamdyke.org as they simply indicate the following: /usr/local/bin/spamdyke --log-level=verbose ... The 3 dots being something that I'm not clear on as to what else should be placed there. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Does not default to maillog Re: [qmailtoaster] Spamdyke logging with QMT integration
Sorry, Correction to typo on my previous notes: There are spamdyke entries being captured in the /var/log/qmail/send/current to There are spamdyke entries being capture in the /var/log/qmail/smtp/current file. tim On Mon, July 27, 2009 12:15 pm, Tim Pleiman wrote: Ok, So, tested and cannot get spamdyke logs to work (or they're going some other place that I can't find or into nothing): SPAMDYKE=/usr/local/bin/spamdyke -lverbose SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose SPAMDYKE=/usr/local/bin/spamdyke -ldebug SPAMDYKE=/usr/local/bin/spamdyke --log-level=debug Should be going into maillog as the default. Must be something I'm missing. Must something be done differently/peculiar to the QMT integration to get these logs? There are spamdyke entries being captured in the /var/log/qmail/send/current file, but no matter what I do with the loglevel specifcation on the spamdyke line, it doesn't output them to maillog on its own and it doesn't increase the level of logging in /var/log/qmail/send/current Would like to get those more detailed logs from spamdyke. Any ideas? Thanks, Tim On Mon, July 27, 2009 11:55 am, Tim Pleiman wrote: Actually, I missed it. It's earlier in the documentation at spamdyke.org where the logs typically go: When spamdyke logs to syslog, it uses the LOG_MAIL facility, which typically puts the messages in /var/log/maillog. So, presuming this is true, so I presume that adding the logging options to the SPAMDYKE line in run.spamdyke file will then log spamdyke messages to /var/log/maillog? Everything correct? Will try. Thanks, Tim On Mon, July 27, 2009 11:35 am, Tim Pleiman wrote: Hi all, Presumably, if I want to capture a spamdyke log, I would modify the following in the /var/run/qmail/supervise/run file (which with spamdyke installed with QMT is a symlink to run.spamdyke, so I would modify run.spamdyke): SPAMDYKE=/usr/local/bin/spamdyke to be SPAMDYKE=/usr/local/bin/spamdyke -lverbose or SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose Is this correct? If so, where do the logs go? Do they go to a default location? Or must that be specified? If it must be specified, is the log location to be added after -lverbose or --log-level=verbose as in: SPAMDYKE=/usr/local/bin/spamdyke -lverbose /var/log/spamdyke.log I'm not clear from the documentation at spamdyke.org as they simply indicate the following: /usr/local/bin/spamdyke --log-level=verbose ... The 3 dots being something that I'm not clear on as to what else should be placed there. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA
[qmailtoaster] Never mindRe: [qmailtoaster] Does not default to maillog Re: [qmailtoaster] Spamdyke logging with QMT integration
Log levels increase in the /var/log/qmail/smtp/ logs when you modify the setting in the spamdyke.conf file: log-level=verbose and then log-target=stderr stderr being the /var/log/qmail/smtp/ default in QMT So, I've answered my own question. So, I guess that means that if there is any entry for the log level and location in spamdyke.conf, then that overrides any entry on the spamdyke command line in the run file. Thanks, Tim On Mon, July 27, 2009 12:19 pm, Tim Pleiman wrote: Sorry, Correction to typo on my previous notes: There are spamdyke entries being captured in the /var/log/qmail/send/current to There are spamdyke entries being capture in the /var/log/qmail/smtp/current file. tim On Mon, July 27, 2009 12:15 pm, Tim Pleiman wrote: Ok, So, tested and cannot get spamdyke logs to work (or they're going some other place that I can't find or into nothing): SPAMDYKE=/usr/local/bin/spamdyke -lverbose SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose SPAMDYKE=/usr/local/bin/spamdyke -ldebug SPAMDYKE=/usr/local/bin/spamdyke --log-level=debug Should be going into maillog as the default. Must be something I'm missing. Must something be done differently/peculiar to the QMT integration to get these logs? There are spamdyke entries being captured in the /var/log/qmail/send/current file, but no matter what I do with the loglevel specifcation on the spamdyke line, it doesn't output them to maillog on its own and it doesn't increase the level of logging in /var/log/qmail/send/current Would like to get those more detailed logs from spamdyke. Any ideas? Thanks, Tim On Mon, July 27, 2009 11:55 am, Tim Pleiman wrote: Actually, I missed it. It's earlier in the documentation at spamdyke.org where the logs typically go: When spamdyke logs to syslog, it uses the LOG_MAIL facility, which typically puts the messages in /var/log/maillog. So, presuming this is true, so I presume that adding the logging options to the SPAMDYKE line in run.spamdyke file will then log spamdyke messages to /var/log/maillog? Everything correct? Will try. Thanks, Tim On Mon, July 27, 2009 11:35 am, Tim Pleiman wrote: Hi all, Presumably, if I want to capture a spamdyke log, I would modify the following in the /var/run/qmail/supervise/run file (which with spamdyke installed with QMT is a symlink to run.spamdyke, so I would modify run.spamdyke): SPAMDYKE=/usr/local/bin/spamdyke to be SPAMDYKE=/usr/local/bin/spamdyke -lverbose or SPAMDYKE=/usr/local/bin/spamdyke --log-level=verbose Is this correct? If so, where do the logs go? Do they go to a default location? Or must that be specified? If it must be specified, is the log location to be added after -lverbose or --log-level=verbose as in: SPAMDYKE=/usr/local/bin/spamdyke -lverbose /var/log/spamdyke.log I'm not clear from the documentation at spamdyke.org as they simply indicate the following: /usr/local/bin/spamdyke --log-level=verbose ... The 3 dots being something that I'm not clear on as to what else should be placed there. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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 -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need
[qmailtoaster] Squirrelmail plugins page down...anyone heard how long?
Hi all, I've checked for the past several days now at Squirrelmail.org so I can get the latest versions of plugins that I want, and this is what is on the plugins page: http://www.squirrelmail.org/plugins.php Plugins The plugin system is currently unavailable whilst we investigate a possible server compromise. Driving me nuts. Anyone heard anything about when this might be back up? I'm thinking there must be a mirror somewhere else. Anyone have that URL? Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Squirrelmail plugins page down...anyone heard how long?
On Wed, July 15, 2009 6:50 pm, Jake Vickers wrote: Tim Pleiman wrote: Hi all, I've checked for the past several days now at Squirrelmail.org so I can get the latest versions of plugins that I want, and this is what is on the plugins page: http://www.squirrelmail.org/plugins.php Plugins The plugin system is currently unavailable whilst we investigate a possible server compromise. Driving me nuts. Anyone heard anything about when this might be back up? I'm thinking there must be a mirror somewhere else. Anyone have that URL? Thanks, Tim They have no announced date other than when it's done before it will be back. The major plugins are also located on the SF page (http://sourceforge.net/projects/sm-plugins/files/) and the rest can be found by googling (usually source from BSD ports). Yeah, I found some of the BSD listings and checked the sourceforge page. But, I was hoping to find some of the descriptive information without downloading everything just to read the readmes, maybe add some new ones that weren't easily installable/compatible on my old servers. Couldn't find everything. But, I migrated the ones from my old QMR installs and they are almost all working, including html_mail (which I hate, but certain users insist upon). I'll just have to wait to add additionals and update the versions on existings later. The plugin page at squirrelmail.org has been down since June 19th though--a bit disconcerting. Thanks again, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Missing HELO identifier--Resolved
On Tue, July 14, 2009 11:07 am, Eric Shubert wrote: Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' Eric, Indeed, that's exactly what's going on here. It seems that particular HELO is being picked up from the actual URL domain that you use for login. So, if you login via IP address, that's what you get in the HELO
[qmailtoaster] rhost-check in conjunction with rblsmtpd?
Hi all, Is/has anyone here used rhost_check in conjunction rblsmtpd and QMT to do rDNS lookups on remote hosts for spam filtering? http://www.zentus.com/rhost-check.html I've always compiled this useful tool into my QMR installs in the past to do non-paranoid (-p) tcpserver lookups of the rDNS status of connecting hosts. I always place this lookup immediately prior to all other checks to verify that the connecting server at least HAS some sort of PTR record. It cuts off spam immediately without any other conditions first and avoids hammering the RBLs unnecessarily. It's worked fine with RH9 and EL3. Was wondering if anyone has compiled and installed it on more recent versions of EL--specifically CentOS 5.3-x64. Does the code works with more recent linux releases and x64 versions? Also, in case I'm missing something here and wasting my time, the current CHKUSER isn't doing any rDNS PTR lookups for connection verification/rejection, is it? Thanks! -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] and on Spamdyke (Missing HELO identifier--Resolved)
On Tue, July 14, 2009 5:25 pm, Eric Shubert wrote: Tim Pleiman wrote: On Tue, July 14, 2009 11:07 am, Eric Shubert wrote: Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' Eric, Indeed, that's exactly what's going on here. It seems that particular HELO is being picked up from the actual URL domain that you
Re: [qmailtoaster] how to control infected users
On Tue, July 14, 2009 7:21 am, Lucian Cristian wrote: Karpaha Vinayaham wrote: Dear All One of my user machine was infected by a virus and it start sending lots of spam mails. As the user was using smtp-auth my server accepted the mail. Because of this my server IP is blacklisted, after diagnosing i have blocked the infected machine IP through iptable and scanned for virus. Now the problem is solved, but i wanted to know how to control this behaviour. With Regards Vinay Love Cricket? Check out live scores, photos, video highlights and more. Click here http://in.rd.yahoo.com/tagline_cricket_2/*http://cricket.yahoo.com. I don't know any trojan that can use auth sistem to send emails, classical way is to send mails using it's own server, so blocking destination port 25 for the inside clients should solve the problem, but if there is an aplication that sends mails using auth sistem then we are all doomed :D Regards Lucian Sounds from your description here like you were routing forwarding LAN traffic through the same IP address (same server perhaps) that is hosting your mail. The spam zombie probably wasn't routing via your mail server itself, rather just your IP address interface (on the same machine or otherwise). Spam zombied machines generally send spam directly. In this case, you can either do as Lucian suggests and ban outbound port 25 to forwarding in IPTABLES, or, better yet if possible, route your LAN traffic through a different IP address/interface/server. Also, as I presume the machines on your LAN are Windows machines. Make sure to lock down your client workstations tightly in a controlled manner. If running in a Windows Workgroup, make sure users only have Restricted User (User Group) accounts on a machine by machine basis. If on a Samba domain or Active Directory Domain, also make sure all users are granted only User Group permissions on the Domain. This will help to ensure that users are are not as easily infected in the first place. Unfortunately, in some cases, users must be granted certain slightly elevated permissions on machines for certain software applications to run properly (e.g. Standard User (Power Group). Quickbooks is a notable example of such a badly-designed application. Users in the Power Group can get infected. Also, make sure you are continually educating/informing your users as to network policies/procedures. Users should not open e-mails from untrusted sources, and should never follow links in such emails, and should never follow links in casual e-mails from friends that they receive at the workplace. Use of 3rd party e-mail providers (webmail, et.al), over which you have no control should be discouraged. If a machine shows signs of infection (XP antivirus or other similar bots), users should be educated to unplug the network cable immediately from the wall and contact support. Leave the machine running, and rebooting can cause the infection to become more deeply embedded in the windows registry and/or system32 directory. Anti-virus software on individual machines is proving less and less effective in stopping infection, as the time from virus reporting to AV definition update at the AV vendors can only happen so fast. Zero-hour exploits have exploded, and often the only prevention for these are wise, well-educated users. These are headaches that can't always be prevented by the network admin. I've had two zombie infected machines within the past year, after seeing no infections of any type on my networks for around 8 years. One was a year ago this week and one 2 weeks ago. Both were on machines with elevated permissions. Both were in the same office. The first was a user who was designated as a local office admin. At that point a year ago, I eliminated all users with full admin privileges of any kind. The most recent, however, was on a user's machine with Power Group permissions. Unfortunately, that machine cannot be locked down any further, and that infection slipped by local AV filters. However, in order to get infected, the user had to have followed a malicious link or visit an infected website (probably running IIS). However, you can mitigate these things as above, and I hope this is of some help to you. I know how incredibly painful cleaning up these types of things can be. Good luck! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
[qmailtoaster] Missing HELO identifier
Hi, I'm new to QMT and I'm migrating several servers from old hardware with QMR installations to new hardware running QMT, as QMR just isn't being kept up well anymore, and I'm tired of patching everything up on my own. So far, everything has been running quite well with the new install and subsdquent newmodel updates in the pre-prod testing. But, I can't seem to find where to fix a problem with one of the header HELOs on the localhost with SquirrelMail (or perhaps any virtual domain). I did find reference to this problem in the toaster list archives from this past November here: http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg20877.html However, that does not seem to solve the problem (and in a virtual domain environment, wouldn't make sense, as this HELO would always be fixed), and I can't find other references in the archives that lead me to a solution. Here's a more definitive display of where the problem lies sequentially in the header: Received: from mail.rDNSname.org (HELO mail.servername.org) (xx.xxx.xxx.xxx) by mail.servername.com with AES256-SHA encrypted SMTP; 13 Jul 2009 14:27:14 -0500 Received: (qmail 28786 invoked by uid 89); 13 Jul 2009 19:27:14 - Received: from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) by mail.servername.org with SMTP; 13 Jul 2009 19:27:14 - Received: from xx.xx.xx.xx (SquirrelMail authenticated user postmas...@testdomain.com) by xx.xxx.xxx.xxx with HTTP; Mon, 13 Jul 2009 14:27:14 -0500 Message-ID: 4cd812cb08d79de095811e229fff7d1a.squir...@xx.xxx.xxx.xxx Date: Mon, 13 Jul 2009 14:27:14 -0500 Specifically, this being the problem: Received: from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) Typically, I would expect to see this instead: localhost (HELO mail.virtualservername.org) (127.0.0.1) Typically in QMR, this gets picked up from the appropriate virtual domain==e.g testdomain.com in this case, but with a different method that I can locate in QMT. I've tried adjusting all the Qmail control files, among other things, and I can't seem to figure out why I can't fix this/where to fix this. Probably something simple that I'm just missing vis a vis differences between the installation/deployments of Qmail here (QMR vs. QMT) that I can't figure out. Your help appreciated. Thanks! -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Missing HELO identifier
On Mon, July 13, 2009 3:11 pm, Eric Shubert wrote: Tim Pleiman wrote: Hi, I'm new to QMT and I'm migrating several servers from old hardware with QMR installations to new hardware running QMT, as QMR just isn't being kept up well anymore, and I'm tired of patching everything up on my own. So far, everything has been running quite well with the new install and subsdquent newmodel updates in the pre-prod testing. But, I can't seem to find where to fix a problem with one of the header HELOs on the localhost with SquirrelMail (or perhaps any virtual domain). I did find reference to this problem in the toaster list archives from this past November here: http://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg20877.html However, that does not seem to solve the problem (and in a virtual domain environment, wouldn't make sense, as this HELO would always be fixed), and I can't find other references in the archives that lead me to a solution. Here's a more definitive display of where the problem lies sequentially in the header: Received: from mail.rDNSname.org (HELO mail.servername.org) (xx.xxx.xxx.xxx) by mail.servername.com with AES256-SHA encrypted SMTP; 13 Jul 2009 14:27:14 -0500 Received: (qmail 28786 invoked by uid 89); 13 Jul 2009 19:27:14 - Received: from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) by mail.servername.org with SMTP; 13 Jul 2009 19:27:14 - Received: from xx.xx.xx.xx (SquirrelMail authenticated user postmas...@testdomain.com) by xx.xxx.xxx.xxx with HTTP; Mon, 13 Jul 2009 14:27:14 -0500 Message-ID: 4cd812cb08d79de095811e229fff7d1a.squir...@xx.xxx.xxx.xxx Date: Mon, 13 Jul 2009 14:27:14 -0500 Specifically, this being the problem: Received: from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) Typically, I would expect to see this instead: localhost (HELO mail.virtualservername.org) (127.0.0.1) Typically in QMR, this gets picked up from the appropriate virtual domain==e.g testdomain.com in this case, but with a different method that I can locate in QMT. I've tried adjusting all the Qmail control files, among other things, and I can't seem to figure out why I can't fix this/where to fix this. Probably something simple that I'm just missing vis a vis differences between the installation/deployments of Qmail here (QMR vs. QMT) that I can't figure out. Your help appreciated. Thanks! What's in your /var/qmail/control/me file? -- -Eric 'shubes' /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Missing HELO identifier
On Mon, July 13, 2009 3:46 pm, Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. Yes, but that's not the problem I'm having in testing here. The mailserver HELOS themselves are identifying properly at every other point. The problem here is related to only one particular HELO--where I would expect the name of the particular virtual domain to be injected into the HELO identifier at that point in the process. It seems to be a problem referenced elsewhere with respect to QMT too (unknowns, but hard to tell from the various archive questions), something I never saw in QMR, as that injected the virtual domain into this HELO identifier position. Thanks, Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
Re: [qmailtoaster] Missing HELO identifier
On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - 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
