Mailing List Archive: RE: MailFormTo (was: embperl bug?)

RE: MailFormTo (was: embperl bug?)

Jul 6, 2000, 12:40 PM

Post #1 of 3 (1003 views)

Hi,
>
> was working today on the standard MailFormTo utility function, when I ran
> into a problem trying to get the emails sent succesfully.
>
> When connecting to a Qmail or SendMail MTA, mail will not be accepted
> by the server because of missing parts in the way Embperl.pm uses
> Net::SMTP.
>
> The mailserver disconnects because Embperl is not sending a HELO to the
> server.
>
> The next thing in Embperl that caused problems on our servers (which are
> all RedHat based) was the fact that Embperl did not send a "MAIL" command
> to the mailserver.
>
> Our (messy) workaround for this in Embperl.pm was to add the following:
>
> --- snippet from Embperl.pm ---
>
> $smtp = Net::SMTP->new($ENV{'EMBPERL_MAILHOST'} || 'localhost', Debug =>
> $ENV{'EMBPERL_MAILDEBUG'}, Hello => 'solbors.no') or die "Cannot connect
> to mailhost" ;
>
> $smtp->mail("receipt\@solbors.no");
>
> ---- end of snippet -----------
>
> I expect that more users might run into similar problems. The solution we
> came up with is quite messy, but we just didn't have the time for a more
> elegant solution.
>
> We encoutered the problem on RedHat 5.x and 6.x machines, running QMail
> and SendMail 8.9.x MTAs
>

Depends on which version of Embperl you are using. Newer versions contains a
mail method call:

{ $smtp->mail($ENV{'EMBPERL_MAILFROM'} ||
"WWW-Server\@$ENV{SERVER_NAME}");}

so you are able to set

PerlSetEnv EMBPERL_MAILFROM receipt@solbors.no

in your httpd.conf. This was really a problem with older (< 1.2.1) version
of Embperl, but since your example contains the EMBPERL_MAILDEBUG already,
it must be 1.2.1 or above and should already know EMBPERL_MAILFROM.

For the hello parameter Net::SMTP normaly takes a reasonable default value,
so there was no need in the past to explicitly specify this parameter.

You may set EMBPERL_MAILDEBUG to 1 in your httpd.conf and watch in your
syslog the dialog between your mailserver and Net::SMTP. If there is really
no helo command in it, we have to take a closer look, but on my systems
(sendmail 8.8.x and 8.9.x and postfix) I never run into this problems.

Gerald

P.S. Please send any further questions to the Embperl mailing list, so
others can participate

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

RE: MailFormTo (was: embperl bug?) [ In reply to ]

remco at xgov

Jul 10, 2000, 3:09 AM

Post #2 of 3 (972 views)

Permalink

> > was working today on the standard MailFormTo utility function, when I ran
> > into a problem trying to get the emails sent succesfully.
> >
> > When connecting to a Qmail or SendMail MTA, mail will not be accepted
> > by the server because of missing parts in the way Embperl.pm uses
> > Net::SMTP.
> >
> > The mailserver disconnects because Embperl is not sending a HELO to the
> > server.
> >
> > The next thing in Embperl that caused problems on our servers (which are
> > all RedHat based) was the fact that Embperl did not send a "MAIL" command
> > to the mailserver.
> >
> > Our (messy) workaround for this in Embperl.pm was to add the following:
> >
> > --- snippet from Embperl.pm ---
> >
> > $smtp = Net::SMTP->new($ENV{'EMBPERL_MAILHOST'} || 'localhost', Debug =>
> > $ENV{'EMBPERL_MAILDEBUG'}, Hello => 'solbors.no') or die "Cannot connect
> > to mailhost" ;
> >
> > $smtp->mail("receipt\@solbors.no");
> >
> > ---- end of snippet -----------
> >
> > I expect that more users might run into similar problems. The solution we
> > came up with is quite messy, but we just didn't have the time for a more
> > elegant solution.
> >
> > We encoutered the problem on RedHat 5.x and 6.x machines, running QMail
> > and SendMail 8.9.x MTAs
> >
>
> Depends on which version of Embperl you are using. Newer versions contains a
> mail method call:
>
> { $smtp->mail($ENV{'EMBPERL_MAILFROM'} ||
> "WWW-Server\@$ENV{SERVER_NAME}");}
>
> so you are able to set
>
> PerlSetEnv EMBPERL_MAILFROM receipt@solbors.no
>
> in your httpd.conf. This was really a problem with older (< 1.2.1) version
> of Embperl, but since your example contains the EMBPERL_MAILDEBUG already,
> it must be 1.2.1 or above and should already know EMBPERL_MAILFROM.

Yes, that is correct. but the fact whether or not you actually use this
variable does not appear to affect the 'bug'.

The problem lies in the fact that the mailserver is expecting a
"MAIL" command. As long as that one is not send (and it isn't since
embperl does't even get that far, Net::SMTP doesn't send it and therefor
the mailserver kindly disconnects us), we can't properly send the form
out.

> For the hello parameter Net::SMTP normaly takes a reasonable default value,
> so there was no need in the past to explicitly specify this parameter.

Apparently it doesn't take a reasonable default value. RedHat 6.x and 5.x
standard installed versions of SendMail expect you to explicitely send
that HELO parameter. Out-of-the-box Embperl does not support it.

One could argue ofcourse that this is something that Net::SMTP should take
care of, but including an optional parameter in Embperl isn't that much
more effort and would at least solve the problem.

> You may set EMBPERL_MAILDEBUG to 1 in your httpd.conf and watch in your
> syslog the dialog between your mailserver and Net::SMTP. If there is really

I did that already, which is how I came to include the HELO and MAIL
parameters in my Embperl.pm

> no helo command in it, we have to take a closer look, but on my systems
> (sendmail 8.8.x and 8.9.x and postfix) I never run into this problems.

So far I can't get any forms send out with an unmodified Embperl (latest
release) on RedHat 5.x/SendMail and RedHat 6.x/qmail

> P.S. Please send any further questions to the Embperl mailing list, so
> others can participate

done :) Thanks for the support!

regards,
Remco Brink
SOL Bors developer

RE: MailFormTo (was: embperl bug?) [ In reply to ]

richter at ecos

Jul 14, 2000, 11:10 AM

Post #3 of 3 (970 views)

Permalink

>
> Yes, that is correct. but the fact whether or not you actually use this
> variable does not appear to affect the 'bug'.
>
> The problem lies in the fact that the mailserver is expecting a
> "MAIL" command. As long as that one is not send (and it isn't since
> embperl does't even get that far, Net::SMTP doesn't send it and therefor
> the mailserver kindly disconnects us), we can't properly send the form
> out.
>

The mail command is in the Embperl source, but as far as I see, the problem
is the missing HELO command, so the NET::SMTP constructors fails.

> > For the hello parameter Net::SMTP normaly takes a reasonable
> default value,
> > so there was no need in the past to explicitly specify this parameter.
>
> Apparently it doesn't take a reasonable default value. RedHat 6.x and 5.x
> standard installed versions of SendMail expect you to explicitely send
> that HELO parameter. Out-of-the-box Embperl does not support it.
>
> One could argue ofcourse that this is something that Net::SMTP should take
> care of, but including an optional parameter in Embperl isn't that much
> more effort and would at least solve the problem.
>

ok, nobody reported problems with this so far, but it's no problem to
include such a configuration variable to explicitly send the HELO command. I
will add this in the next release of Embperl.

Does it work when you explicitly send the HELO command (as you decribed in
your patch:

$smtp = Net::SMTP->new($ENV{'EMBPERL_MAILHOST'} || 'localhost', Debug =>
$ENV{'EMBPERL_MAILDEBUG'}, Hello => 'solbors.no') or die "Cannot connect
to mailhost" ;

)

and set the

PerlSetEnv EMBPERL_MAILFROM receipt@solbors.no

and _not_ include your second part of the patch (the mail command). As far
as I understand your problem, this should work.

Please let me know if this is ok, so the next release can contains the right
code

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------