Why is this simple script not sending email?

F

fastjack

#My email is in the "To: " line. just not listed below for spam reasons.

#!/usr/bin/perl

$mailprog = '/usr/lib/sendmail -i -t';
open(MAIL,"|$mailprog");

print MAIL "To: (e-mail address removed)\n";
print MAIL "From: (e-mail address removed) (Test )\n";
# Add Ability to send HTML
print MAIL "Content-type: text/html\n";

# Check for Message Subject
print MAIL "Subject: Test\n\n";

print MAIL "This is a test\n\n";
close (MAIL);
print "Content-type: text/html\n\n";
print "<html><h1>The Email has been sent</h1></html>\n";
 
P

Paul Lalli

#My email is in the "To: " line. just not listed below for spam reasons.

#!/usr/bin/perl
use strict;
use warnings;
$mailprog = '/usr/lib/sendmail -i -t';
my $mailprog = '/usr/lib/sendmail -i -t';
open(MAIL,"|$mailprog");

open MAIL, "|$mailprog" or die "Cannot start mail program: $!";
print MAIL "To: (e-mail address removed)\n";
print MAIL "From: (e-mail address removed) (Test )\n";

I'm not convinced that's an acceptable header, though I could be wrong.
# Add Ability to send HTML
print MAIL "Content-type: text/html\n";

# Check for Message Subject
print MAIL "Subject: Test\n\n";

print MAIL "This is a test\n\n";
close (MAIL);
print "Content-type: text/html\n\n";
print "<html><h1>The Email has been sent</h1></html>\n";

If this revised script doesn't die at the open line, then there's
something wrong with the information you're sending to sendmail. If it
does, figure out what to do based on the error message. (If you're
running this via a webserver, as it appears, you will need to check the
server logs and/or run the script on the command line to see the error
message).

Paul Lalli
 
D

David Efflandt

#My email is in the "To: " line. just not listed below for spam reasons.

One reason your script does not work is because "@domain" and "@test" are
list variables when in enclosed in double quotes, so your addresses are
invalid. You either need to escape the "\@" or use single quotes around
that part of it like 'To: (e-mail address removed)'."\n"

However, you also fail to test your open() and close() to see if there are
any other problems.
 
K

Kevin Collins

#My email is in the "To: " line. just not listed below for spam reasons.

#!/usr/bin/perl

$mailprog = '/usr/lib/sendmail -i -t';
open(MAIL,"|$mailprog");

Why not try:
open(MAIL,"|$mailprog") || die "can't open $mailprog: $!";

And sense this appears to be CGI, add the following BEFORE the above line:

use CGI::Carp qw(fatalsToBrowser);
print MAIL "To: (e-mail address removed)\n";
print MAIL "From: (e-mail address removed) (Test )\n";
# Add Ability to send HTML
print MAIL "Content-type: text/html\n";

# Check for Message Subject
print MAIL "Subject: Test\n\n";

print MAIL "This is a test\n\n";
close (MAIL);
print "Content-type: text/html\n\n";
print "<html><h1>The Email has been sent</h1></html>\n";

Do you have access to the mail logs? Do you know for certain that sendmail is
in the location you have specified?

Kevin
 
K

Kevin Collins

One reason your script does not work is because "@domain" and "@test" are
list variables when in enclosed in double quotes, so your addresses are
invalid. You either need to escape the "\@" or use single quotes around
that part of it like 'To: (e-mail address removed)'."\n"

However, you also fail to test your open() and close() to see if there are
any other problems.

Not to sound like a smartass, but why would you test a close()? I have never
thought about it before I read this post... If it doesn't close with close(),
it definitely will on program termination.
 
E

Eric Schwartz

Not to sound like a smartass, but why would you test a close()? I have never
thought about it before I read this post... If it doesn't close with close(),
it definitely will on program termination.

close() can fail in a number of odd, but potentially care-about-able
cases. If a filehandle's buffer contains more data than will fit on
the disk when it's flush()ed, the close() can fail. If the filehandle
is a socket endpoint, bad things can happen there, too. Anyway, it
doesn't really hurt anything, and it can give you more information on
a failure if you use it, so why not?

-=Eric
 
K

Kevin Collins

close() can fail in a number of odd, but potentially care-about-able
cases. If a filehandle's buffer contains more data than will fit on
the disk when it's flush()ed, the close() can fail. If the filehandle
is a socket endpoint, bad things can happen there, too. Anyway, it
doesn't really hurt anything, and it can give you more information on
a failure if you use it, so why not?

Ok, those sound like intelligent reasons to me...

Kevin
 
J

John W. Krahn

David said:
One reason your script does not work is because "@domain" and "@test" are
list variables when in enclosed in double quotes, so your addresses are
^^^^^^^^^^^^^^
Perl doesn't have list variables, just scalars, arrays and hashes.

perldoc -q "What is the difference between a list and an array"



John
 
J

John W. Krahn

Kevin said:
Not to sound like a smartass, but why would you test a close()? I have never
thought about it before I read this post... If it doesn't close with close(),
it definitely will on program termination.

perldoc perlipc
[snip]

Using open() for IPC
Perl's basic open() statement can also be used for unidi­
rectional interprocess communication by either appending
or prepending a pipe symbol to the second argument to
open(). Here's how to start something up in a child pro­
cess you intend to write to:

open(SPOOLER, "| cat -v | lpr -h 2>/dev/null")
|| die "can't fork: $!";
local $SIG{PIPE} = sub { die "spooler pipe broke" };
print SPOOLER "stuff\n";
close SPOOLER || die "bad spool: $! $?";

[snip]

Be careful to check both the open() and the close() return
values. If you're writing to a pipe, you should also trap
SIGPIPE. Otherwise, think of what happens when you start
up a pipe to a command that doesn't exist: the open() will
in all likelihood succeed (it only reflects the fork()'s
success), but then your output will fail--spectacularly.
Perl can't know whether the command worked because your
command is actually running in a separate process whose
exec() might have failed. Therefore, while readers of
bogus commands return just a quick end of file, writers to
bogus command will trigger a signal they'd better be pre­
pared to handle. Consider:

open(FH, "|bogus") or die "can't fork: $!";
print FH "bang\n" or die "can't write: $!";
close FH or die "can't close: $!";

That won't blow up until the close, and it will blow up
with a SIGPIPE. To catch it, you could use this:

$SIG{PIPE} = 'IGNORE';
open(FH, "|bogus") or die "can't fork: $!";
print FH "bang\n" or die "can't write: $!";
close FH or die "can't close: status=$?";



John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top