Thanks for the response Eric. First off - the qmail-toaster upgrade did not stomp on my original working eMPF file. :) Secondly, I looked in the backups directory and all the files contained in the /var/qmail/control directory get backed up. You may not need to tweak anything in the qtp-newmodel script.
I am going to attempt to explain what is happening. There is probably alot more information that I can supply. I just don't know what all to put here. I am running qmail-toaster on a Linux CentOS 4.7 system. I have named this server mercury. It has been in productions for several years. I am using qtp-newmodel to upgrade it from time to time. This week I upgraded. I also have a webserver named jupiter. Same Linux CentOS 4.7 version. It is also running qmail-toaster. It has contact us email forms on some of the websites I host. If the website is domainA.com then the email goes to [email protected] by default. If domain is domainB.com then email from the form goes to [email protected] When the person fills out the form, they can opt to have a copy sent to an email address they supply. Pretty basic. Most sites have them. I have set /var/qmail/control/smtproutes on jupiter to send all emails to mercury for distribution both internally and externally. On mercury I use eMPF. I have used it sucessfully for over a year. I have checked it, and the config has not changed since the upgrade. I only have one client that uses it, so I only have one rule for one domain inside the config file (/var/qmail/control/policy). The rule says all email addresses can send and receive both internal and external emails except for a couple of email addresses that can only send and receive internal emails. ie [email protected]. When I use an email client (thunderbird, or squirrelmail) and send either internally or externally, email is successful. When [email protected] sends email to [email protected] it works properly and if the try to send an email to any other domain, it is refused by eMPF policy. So in this case eMPF is working properly. Now if I go to domainA.com and fill out the "contact us" form giving my email address as [email protected] and opt to receive a copy of the email, this is where it breaks. The [email protected] receives an email, but [email protected] never does. Looking in the /var/log/send/current file on jupiter (webserver) it has a message stating: @400000004aa1615433bd143c delivery 136: failure: User_and_password_not_set,_continuing_without_authentication./207.224.XXX.XXX_does_not_like_recipient./ Remote_host_said:[email protected]_(#5.0.0_denied_by_policy)/Giving_up_on_207.224.XXX.XXX./ However, if I fill out the same form using an external email account [email protected] both emails are delivered successfully. I have seen the "denied_by_policy" message and it is associated with eMPF. If I emtpy the eMPF's policy file, reload qmail, and fill out the web form again, then all emails go through. Both internal and external. I don't understand why emails to domainB.com are being denied when domainB.com has no entries in the eMPF policy file and by default is permitted to send and receive any email. I have also checked my tcp.smtp file - it has not changed except for the "NOP0FCHECK="1" in the 127.:allow line. I was thinking of trying to use recordio and see what I get, but haven't gotten that far. Any suggestions on how I can troubleshoot this further? Really sorry about how convoluted this is, but I can't be the only one needing to prevent certain users from sending and receiving external emails. Maybe there is a better way. If so, I am all ears. Up to now, eMPF has performed admirably. Thanks, Dave Eric Shubert wrote: > In /usr/src/qtp-upgrade/ you'll see: > .) the log/ directory, which contains every build log that's been > done. .) the SRPMS/ directory. While you've removed the .src.rpm > files, there are also newmodel-list-yyyymmdd-hhmmss.txt files, which > contain the package list for the upgrade that was selected on the > specified date. > .) the backups/ directory. There is are backup-yyyymmdd-hhmm > directories here that contain configuration data, in the event that an > upgrade inadvertently clobbers a configuration file. > > I'm guessing here that perhaps the qmail-toaster upgrade with eMPF > added might have clobbered your previous eMPF configuration file. > Unfortunately, as this is a new feature, a backup of your previous > configuration may or may not have been made by qtp-newmodel, depending > on where the configuration file is located. Please check the backups/ > and see if it's there or not. If it is, great. If it's not, I'm afraid > you might be out of luck. > > Let us know and we'll get things fixed up as best we can. The > qmail-toaster.spec file might need to be tweaked for the eMPF > configuration file(s), and qtp-newmodel might need to add the eMPF > configuration file(s) into it's backup section. > > Or, your problem could be something else. ;) > > > [email protected] wrote: >> Thanks Jake. At this time I really just wanted to know if anything >> changed with eMPF with regards to qmail-toaster. I understand that I >> haven't given much information here. I need to be able to understand >> what is happening before I can attempt to describe it here. I plan to do >> some more troubleshooting and get the information (logs, file listings, >> etc) together first. Then perhaps I can post something more intelligent. >> Thanks again for your speedy reply. >> Dave >> >> Jake Vickers wrote: >>> [email protected] wrote: >>>> Hi all, >>>> On Tuesday Sept 1, I downloaded and installed the qmail-toaster >>>> updates >>>> via qtp new-model. It had been several months since I had upgraded. >>>> I do >>>> not remember what packages were downloaded and upgraded. I am running >>>> CentOS 4.7(final) 32 bit Linux. >>>> >>>> Is there a way to find out what packages would have been marked for >>>> upgrades? I answered "yes" when asked if I wanted to remove the source >>>> rpm's etc. >>>> >>>> More exactly, I am curious if the eMPF packages was upgraded in the >>>> last >>>> few months. I have been using empF without issues, but after the >>>> upgrade, I have to run an empty /var/qmail/control/policy file. >>>> Basically, I can no longer use eMPF. >>>> >>>> Before I go into the details, I want to try to troubleshoot this a >>>> little bit more. >>>> >>>> >>> The patch did not change. >>> In the qtp-newmodel logs will be an account of what packages were >>> updated/changed. >>> Can you provide more information as to why you think it is not working? >>> I do not use the eMPF policies myself, but there is not enough >>> information here to guess as to what the issue may be. >>> >>> > > --------------------------------------------------------------------------------- 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: [email protected] For additional commands, e-mail: [email protected]
