Bounce.cgi and Postfix

[funston]

Hi Dean,

Thank you for your help those were interesting leads.

If I was using Fedora Core 5 I could use a utility application called audit2allow to analyze the audit log to see which SELinux policies are blocking me, e.g. audit2allow -i /var/log/audit/audit.log -l, audit2allow -l -i /var/log/messages and especially the command, audit2allow -d   (i.e. denials from avc or access vector cache)

This command will add the proper resources if using Fedora Core 4 or below:
yum install selinux-policy-targeted-sources selinux-policy-strict-sources

Add the output lines from the audit2allow commands above inside the local.te file located here: /etc/selinux/targeted/src/policy/domains/misc/local.te
 then make and activate the new policy:

cd /etc/selinux/targeted/src/policy/
# make load

Repeat the process until audit2allow produces no output.

Be carefull not to use allow for everything, just the stuff that is blocking you. dontaudit command can be used instead of allow, so it doesn't complain anymore about that particular denial.

Example of how to use dontaudit stead of allow: dontaudit httpd_sys_script_t httpd_sys_script_ro_t:dir { write };
so as to silence the complaint if it's dangerous to allow.


Kind Regards,
Frank Eckdall :wink:
P.D. Sometimes you have to run setenforce 0 to change a context label. Just don't forget to run setenforce 1 after changing a context label.

[funston]

Thank you Dean!
                                              and
                                     Thank you Ken!

A solution has been found.

Thank you for all your help!

Yours very sincerely and respectfully,
Frank F Eckdall
P.D. Happy New Year

[funston]

Hi Dean,

The solution I found here suddenly stopped working. I have no idea why, so I studied up on tuning the policy file with audit2allow etc..

I have changed the policy so that I have no more denied pid, services or daemons, with respect to postfix.

Here is what the maillog says:
postfix/local[23561]: 9DC8D530: to=<useraliase@mydomain.net>, relay=local, delay=1, status=sent (delivered to command: /home/useralias/public_html/cgi-bin/signup-list1.cgi)

As you can see there are no more permssion problems and the email user is indeed signed up to the list, in fact to any list I choose, however now the problem is that a Welcome Email is not sent.

I need a clue here. Do you have any idea why I am able to signup successfully,i.e. by sending a email to signup-list1.cgi via the following ccde: useraliase: "|/home/useralias/public_html/cgi-bin/signup-list1.cgi" inside the /etc/postfix/aliases file? Yet no Welcome Email is ever sent!

Tanks Beforehand.

Regards,
Frank Eckdall
P.D. Perhaps I should add that I can go into ListMail Pro and manually send the welcome email to the newly signed up user. I hope that helps. FYI Turning off SELinux does not resolve this problem

[DW]

Hi Frank,

If the user is added to ListMail they should be sent the welcome message, if enabled for that list, immediately afterwards from the same script.  The message is sent with the PHP mail() function and I don't see a reason why that wouldn't be able to run...  You report the welcome message works when manually adding users - what about from a standard signup form? (Or right from the "List Settings" -> "Signup Code" preview)  If manual addition and signup both work, and the signup.cgi scripts used to work,  I'm stumped.

Regards

[funston]

Hi Dean,

Thank you for your response.

Yes, the "Send welcome email on signup or when confirmed" is checked ie activated.

No, when I add a user manually MailList Pro doesn't send the Welcome Mail. However, I can Quick Load a welcome message and I can then send welcome message and send it manually, and it arrives at its destination.

Also, double opt in no longer works.

Yes then no, the signup code or signup.php or Signup Form produces the following message and the user is  signed up to the user database successfully. However no introductory email is received.:

Thanks for signing up, .
Your email address useralias@mydomain.net will be kept safe!

You will receive an introductory email in a moment.

When I use the double opt in I get the following message but no email message is sent, and thus not able to signup to list.

Before we add you to our database, we must verify your email address. Please check your email for the
confirmation  message and click the link provided to finalize your subscription.

I hope this clarifies what I said earlier and answers what you asked me.

Regards,
Frank Eckdall

[DW]

Frank,

Welcome, confirmation and some notification emails are sent with internal PHP mail() regardless of whether SMTP is enabled or not.  I suspect there may be a problem with this function.

The PHP code found on this page, when copied into a file named test.php, uploaded to your server and browsed to, should result in an email to your (preferably remote) account.

Regards

[funston]

Dean,

When I browse to the script it reveals this:
Friday, January 5th 10:32am CST
testing mail() function..
sending mail..

The mailtest.php script fails to send a email to my remote address.

Here is my php info:
http://www.maestrodigital.net/test.php

Is my php broken? Does php.ini need a change in it's configuration?

Thank you for your help

Regards
Frank

[DW]

Frank,

I don't see anything out of the ordinary in your phpinfo()... There must be a problem somewhere between initiation and delivery of the message.  It looks like PHP calls "/usr/sbin/sendmail -t -i" for all instances of email.  I would check the existence and permissions of the /usr/sbin/sendmail binary/symlink Maybe you can find the process and do a trace, although it would only be running for a second...

Regards

[funston]

Dean,

Could you be more explicit here? I'm not sure what you want me to do.

thanks

Regards,
Frank Eckdall

[DW]

Hi Frank,

I haven't experienced this problem or done what I suggested before... I'm just trying to figure out ways to figure out where the process is failing.  Basically, if my understanding is correct, you have a problem with PHP mail().  The PHP -> sendmail symlink -> postfix connection may need to be investigated or packages could simply need to be reinstalled.  I was suggesting trying to somehow do a complicated "strace" so you could see what's happening behind the scenes with the running program (that is, when PHP loads the connection to postfix).  For me, troubleshooting this particular connection is new and my knowledge is not advanced enough to know whether or not it is possible to figure out what's wrong with this method.   It is very difficult for me to offer any more suggestions or advice without direct access to the server...  Do you have anyone else, such as at your server provider, who might be familiar with the system and willing to investigate?

Regards

[funston]

Hi Dean,

Thank you for your reply.

What I have done is run a backup I made on 24 Dec 2006 when everything seemed to be working. Then basically reproduced the audit2allow procedure mentioned above and re-read my change log notes.

Using audit2allow. a better understanding of the message and error logs plus information from my last analysis of the necessary lines needed inside the local.te file I got it working again, this time I got the Welcome message. I can't tell you what a relief it was to get the Welcome message after the successful signup. I don't know how the php mail got broken.

At any rate everything associated with ListMail Pro is working now, except link tracking that I know is coming from Venezuela. Link tracking just shows question marks instead of their emails for my Venezuelan friends.

Maybe I was to aggressive while learning how to tune the policy file and somehow broke the php or sendmail to postfix. Or, unwittingly changed some context labels late at night and got tired.

It was worth the effort to learn how to modify the policy file for SELinux. I have no one to help me here in Emporia Kansas. Mostly just hicks here and my dog. My dog refuses to study.

Thanks again for all your help.

Kind regards,
Frank Eckdall :wink: