RE: [Exim] PHP Form to send emails with Exim

Inizio della pagina
Delete this message
Reply to this message
Autore: Dan Muey
Data:  
To: Rick Cooper, exim-users
Oggetto: RE: [Exim] PHP Form to send emails with Exim
> > > answer the question.
> >
> > I did, my solution solved the problem by removing the problem.
> > Use Perl to an SMTP session with Exim instead of piping to a
> > program like PHP's mail() does. Much less places it
> > can break, no?
> >
> > And no paths to worry about or config or if /usr/bin/sendmail
> > links to exim properly, etc etc.
> >
> > Perl -> Send
> > [Perl|PHP|Python|Etc] -> sendmail -> Exim -> Send
> >
>
> I tried to be quiet, but this simply isn't accurate. Non of the
> web mail forms I write in PHP use sendmail, actually I probably
> haven't used the mail() function for at least a year for anything


But the OP was using mail()

> but simple text only stuff. $mail->send(array($To), 'smtp'); is
> right out of my SystemMailer script. That line sends muti-part,
> ecoded, you name it and the 'smtp' part should give a clue it's
> not headed for sendmail. mail() is a simple, fast easy way to
> handle sending simple text, there are classes that are for the
> more complex things just as there are in perl. And programming
> dynamic web pages in perl is cumbersome and slow compared to
> php.. that is just a fact.


Ok, I really didn't mean to start something here, I apologize to everyone.

As someone else stated the "facts" usually depend on the programmer.

My original point was, maybe instead of using mail() , like he was asking about,
since there are so many unknowns, is to do an SMTP session to "cut out the
middle man" so to speak. I listed a couple modules to help him do this
if he wants. Yes I should have left out the slams as it clouded the point I
was trying to make, my fault.

>
> > >
> > > if you can't answer the question, then why are you posting?
> >
> > I did answer the question.
> >
> > >
> > > in this particular case, telling someone they're using the
> > > wrong language is not answering the question (there are times
> >
> > I didn't say "wrong" I said *better*, way different.
> >
> > > when telling someone they're using the wrong language may be
> > > a valid answer, but not when someone wants to use php to send
> > > email. i just used php to send email out through exim
> > > yesterday. to me it seems quite clear that it is possible to
> > > answer this question without advising a language change while
> > > making a gratuitous cheap shot in the process.)
> >
> > But its so easy to shoot at PHP because.. Sorry no
> > more shooting :)
> >
>
> So, what is better about perl? Obviously your knowledge of PHP is


As everyone stated, a lot depends on the programmer. I bought a PHP book and
learned about all the goodies I was wanting to do.
There were always issues with getting certain features to work and the ISPs
eventually gave up trying to get certain things to go for me because it
was taking so much of their time and killing apache in the process.

Then when I was an admin, same thing, a customer wanted to use a certain
PHP system and it needed some special thign installed/enabled and I can
only thing of one time PHP was not an issue and that was a super simple
web page that just did a query and used the results on a page.

So its not my knowledge that's the problem 100% its also my experience.
Maybe if PHP just worked right, our of the box, on many platforms, for me like Perl
does I'd use it more.

But again that's just me, I shouldn't have let that show through. I should have
just stated my alternate idea and left language completely out of it.

> limited and thus perl must be better. So I guess if you know say,
> Pascal, well and C just a bit then Pascal must be better? I once
> had someone tell me you couldn't write a daemon in php, same
> fella didn't know what --enable-pcntl meant. PHP, like perl, is
> limited by the programmer more so than the language.
>


Amen! I love everyone!

>
> > >
> > > i have laboriously taught myself not to reply to tell people
> > > to use a different OS/Database/whatever over the years. i'm
> > > not always successful at it, but i try. i wish others would
> > > attempt to do the same.