Re: [Rolodap-develop] Email System

[Philip W. <p.g...@st...>]

I had a thought yesterday. Could the problem with the ldapsearch call be that 
sendmail.phtml uses the php executable, while the rest of Rolodap uses 
mod_php.so?
Has anyone successfully managed to send emails from Rolodap, and if so what 
distro / php version / ldap version are you using?

Phil.

On Friday 05 November 2004 10:43, Philip Ward wrote:
> Hi All,
>
> The email system has been a bit of a chore.
> I've finally managed to get something running and sending emails.
> I'll go over the problems and solutions for anyone who is interested.
> Firstly I figured that allowing only one attachment was a tad mean, so I
> added the ability to add more attachments using "More Attachments" and
> "Fewer Attachments" buttons. This meant that mailform.phtml has to be its
> own "action", so that clicking the buttons brings you back to it. I moved
> the functionality of startmailer.phtml into mailform.phtml inside an
> "if($send)" condition. Startmailer.phtml is now redundant.
> Various changes had to be made to mailform.phtml and sendmail.phtml in
> order to handle an array of attachments rather than a single one.
>
> My next headache was getting sendmail.phtml to run. On my system (Debian
> Woody) the php executable is /usr/bin/php4. I've hard coded it for now.
> Perhaps PHPEXEC should be a setting in rolodap.conf. I'll see about adding
> this at a later date. Until then make sure that your correct php binary is
> referenced.
>
> sendmail.phtml would not run. In depth analysis showed it crashing on the
> ldapsearch call. I've no idea why it would crash. I've tried looking at the
> slapd debug output but have had no flashes of inspiration as yet. My
> interrim fix was to pass a list of email addresses rather than a list of
> uids from mailform.phtml to sendmail.phtml. This way the ldapsearch is
> unnecessary for determining the email addresses (and therefore commented
> out), however it means that placeholders do not work (ie using <firstname>
> or <homephone> in the email will not result in the actual data being mapped
> in - again this has been commented out). I'd like to get this fixed, but
> will have to put it on the back burner for now.
>
> Finally support/smtp_mail.inc had a REALLY annoying bug and I had to
> monitor smtp traffic to find it. The MAIL FROM and RCPT TO commands had
> spaces before the colons (ie "MAIL FROM :" instead of the proper "MAIL
> FROM:"). Once fixed emails went out. I don't know if these ever worked, or
> if some mail servers could handle the error but both my ISP's exim server
> and my local postfix server got upset.
>
> So, here are the files affected:-
> mailform.phtml
> startmailer.phtml - now redundant
> sendmail.phtml - lots of functionality commented out
> support/smtp_mail.inc - two minor but very annoying bugs fixed
>
> While I'm here, other things I'd like to add to the email system are
> signatures (set up via user preferences) and perhaps a more fully featured
> html email editor. Perhaps we can integrate something like Ekit
> (http://www.hexidec.com/ekit.php). Anyone interested in doing these feel
> free, as I'll be working on an email audit trail for the next week or so.
>
> Rather than mess around with patches I've attached new versions of the
> three updated files, since I don't think anyone else is looking at the
> email system at the moment.
> All bug reports and fixes greatfully received, flames to /dev/null. ;-)
>
> Regards,
>
> Phil.

-- 
The University of Stirling is a university established in Scotland by
charter at Stirling, FK9 4LA.  Privileged/Confidential Information may
be contained in this message.  If you are not the addressee indicated
in this message (or responsible for delivery of the message to such
person), you may not disclose, copy or deliver this message to anyone
and any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful.  In such case, you should destroy this
message and kindly notify the sender by reply email.  Please advise
immediately if you or your employer do not consent to Internet email
for messages of this kind.