MIME:Lite problem , bad file descriptor

[1DMF]

Hello,

I'm having on occasion members complain of a software error

Failed to connect to mail server: Bad file descriptor

I've done the ole google wotsit banger and the threads i find seem to indicate a mail server issue.

When I told the mail server guys they said this

Unfortunatly we dont support Pearl code as no one here has enough experience with it to answer your question however we can confirm that our servers are all up and running fine.

Apologies that we can not resolve this issue for you.

I explained that the perl runs fine and all threads found indicate it is not a perl code problem, they replied

I have spoken to one of our developers....

He has suggested that you try using the following command from the machine you are running the perl script on

telnet post6.emailfiltering.com 25

if you see the response 220 ......

then you have connected to the mail server and it is correctly responding.

Following that the SMTP conversation will start. Our service runs with no peculiar settings. It will however perform open-relay checks, etc. I am assuming this is an outbound email, so I would advise that you check that the sender email address matches the domains we scan for.

Bad file Descriptor would tend to indicate a local problem. It it is likely that this error is simply mis-reporting/ masking a valid SMTP response from our service. We really need you to tell us the SMTP response code, which we can then diagnose for you.

I'm a little confused, do I really want to issue a telnet command to the mail server , before MIME:Lite tries to send the email?

Is it possible this error is a bogus 'mis-reported' error as they suggest?

This only happens now and again, emails normally get sent ok, so if there was a problem with the perl code , surely it would never work!

either way, how do I work out what is causing the problem and what this error message means.

I beleive it is a connection problem with the mail server, either timing out, refusing connection, or them simply having networking / conectivity problems at the time the email is trying to be sent.

But hey, it could be to do with the internet connection the webserver is connecting from.

What I feel i can be cetain about is the perl code is not at fault (well I hope not having made that statement - lol )

any advice is appreciated.

perl code is here..

##############################
###### SENDMAIL ROUTINE #####
##############################
# USING MIME::Lite;

sub send_pdf {
 
#_[0] = To
#_[1] = From
#_[2] = Subject
#_[3] = Body Text
#_[4] = Filename
#_[5] = File
 
use MIME::Lite;
 
my @TO = split(/\;/, $_[0]);
 
foreach my $to (@TO){
 
    my $msg = MIME::Lite->new(  From    => "$_[1]",
                            To      => "$to",
                            Subject => "$_[2]",
                            Type    => 'multipart/mixed',
                            Timeout => 60 );
 
    $msg->attach(Type        => 'application/pdf',
             Path        => "$_[5]",
             Filename    => "$_[4]");
 
    $msg->attach(Type        => 'TEXT/HTML',
             Data        => "$_[3]");
 
    [b]$msg->send('smtp', "mail.mailserver.com");[/b]
}
}

highlighted is the line where it bombs.

cheers 1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[stevexff]

According to the MIME::Lite docs on CPAN, you can specify a debug option to get more information on the constructor. But I've no idea how verbose it is, what it prints, or where it prints...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[1DMF]

is it likely to print to the screen?

plus it's so hard to get it to error, as it happens now and then.

I'll give it a while and see if any memeber reports additional information, when the error happens again.

I hate these type of bugs/problems , it's not the code per sae and the third party mail server providers aren't being particulary helpful. not our perl code , not our problem, yeah thanks!

oh well , guess i'll just have to suck it and see.

thanks stevexff

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[KevinADC]

Your problem appears to be here:

    $msg->attach(Type        => 'application/pdf',
             Path        => "$_[5]",
             Filename    => "$_[4]");

Most likely "Filename" is not getting defined properly. You should be validating the input before blindly handing it off to the new constructor.

Also, stop putting double-quotes around single scalars, you should not use any quotes:

    $msg->attach(Type        => 'application/pdf',
             Path        => [b]$_[5][/b],
             Filename    => [b]$_[4])[/b];

same with all other scalars, unless you are making a new string: no quotes.

------------------------------------------
- Kevin, perl coder unexceptional!

 

[1DMF]

1. The debug causes the script to produce "the script misbehaved and failed to produce correct headers" error. So have to assume it prints to the screen but is not a 'die' and so no headers are forced!

2. Filename 'should' be defined properly I create it earlier in the code so it's not 'blindly' handling it.

It is part of a bigger picture, I am having to 'on-the-fly' generate a HTML file (which is the email to be sent) write it to the server, then generate an ASP file, which is then accessed via LWP, which generated a PDF from the HTML , I then attach that PDF to the email and sent the HTML email and the attachment.

I know , conveluted, but it is not possible to generate PDF's correctly with PERL, none of the PDF modules work, especially with CSS, and the screen capture module doesn't do it eather, I had a big thread on this a while ago, it just isn't possible for my purposes.

Anyhow, I now use ABCpdf ASP program to do it, it works, so hey ho.

Here is the larger picture

# set array of hash
$form[$[] = \%data;

# Merge with with email template

# Start template 
my $template = HTML::Template->new(  global_vars => 1,
                                            type => 'filename',
                                          source => DIR_TO_DOCS . '/templates/' . $tp,
                               die_on_bad_params => 0) or die "Cannot open " . $tp . " Template file: $!";

# Add variables to Template
$template->param( 'url_to_domain' => URL_TO_DOMAIN );
$template->param( 'form' => \@form );

# Merge template for PDF conversion
$pdf = $template->output;  

# create temporary HTML of content
my $time = time;
my $filename = DIR_TO_HLP . "/forms/$time-$user";
open(FILE,">$filename.html") or die "Failed to create HTML";
flock(FILE, 2);
print FILE "$pdf";
close(FILE);

# create ASP
my $ASP = "<html>
<body>
<%

 Set theDoc = Server.CreateObject(\"ABCpdf6.Doc\")
 theDoc.AddImageUrl \"" . URL_TO_HLP . "/forms/$time-$user.html\"
 theDoc.Save \"" . DIR_TO_DOCS . "/PDF_Forms/$time-$user.pdf\"

%>
PDF Created!
</body>
</html>";

open(FILE,">$filename.asp")  or die "Failed to create ASP";
flock(FILE, 2);
print FILE "$ASP";
close(FILE);

# Run ASP code
use LWP::Simple;
my $url = URL_TO_HLP . "/forms/$time-$user.asp";
my $content = get("$url");
die "Couldn't get ASP file!" unless defined $content;

# Delete temp files
unlink("$filename.html") or die "HTML delete failed!";
unlink("$filename.asp") or die "ASP delete failed!";

# Send Email
&send_pdf("$recipient\@mydomain.com","webmaster\@mydomain.co.uk","$subject","$pdf","$time-$user.pdf",DIR_TO_DOCS . "/PDF_Forms/$time-$user.pdf");

And yes , just look at all those double-quote encapsulated variables, consider my wrist slapped, I will change it!

But as you can see, the file should exist, though maybe i need to do a

if (!-e $pdf){die "PDF creation failed!";}

wot you think?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[1DMF]

ok i added the follwing...

# Check PDF was created ok
my $mypdf = DIR_TO_DOCS . "/PDF_Forms/$time-$user.pdf";
if(!-e  $mypdf){
    die "Failed to create PDF";
}

Twice I managed to get the 'failed to connect:bad file descriptor' , and it never errored with the 'failed PDF' so there is nothing wrong with the PDF or its filename!

HOWEVER, I got a member to test the form submission for me, they got the error, I instantly tried the telnet procedure as per the mailserver providers suggestion, and guess what, the telnet command struggled to connect, I finally got the 220, but only after a while, when normally it is instant, which suggest exactly as I've been saying all along and as the message says, there is a connectivity problem with the webserver -> mailserver , NOT the PERL code!

So does anyone have any suggestions on how I can work out which end it is?

thanks 1DMF



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!

 

[stevexff]

Perhaps you can use Net::SMTP to 'ping' the mail server before you try the MIME::Lite calls? Creating a new Net::SMTP object should do the EHLO/HELO exchange (you can set a timeout to override the default 120s if you want, check the response with one of the methods like banner(), and then quit(). If it's OK, then go ahead with the MIME::Lite call.

I know it's a bit crude, but it will at least allow you to detect that the mail server is misbehaving before you do the real send...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[1DMF]

hmm interesting thought, though the thing is, if the user right clicks the error screen selects 'back' so the form appears again with the data and clicks submit again, 9/10 it works fine.

So with this in mind, it is possible that the Net:SMTP connect fails, but the MIME:Lite would be ok or vice versa, Net:SMTP connects thinks eveything is ok, but then the MIME:Lite fails.

I never had these problems when using just Net:SMTP , only that can't send emails with attachments!

I've considered creating the email with a hyperlink to the PDF for download, only these PDF's are temp files, where a log of all temp files created by the members are stored in SQL and when they log off they are all deleted from the server.

I could write it so a script 'grabs' the PDF for download and then marks it for deletion, but again, alot of work and storage space for what esentially are temporary files.

plus if the DL failed or the file got corrupt on DL , the link would no longer work as the file is then deleted, plus if they tried the link some time down the road, again it would no longer exist.

is it possible to create some kind of mechanism from within MIME:Lite to say, loop until you connect , once connected send email?

from what I see the method for MIME:Lite is send the email , which makes the connection or dies with the error.

I've been considering editing the MIME:Lite module, so instead of just displaying the 'failed to connect' error, it also says

Please right mouse click this page, select 'back' from the menu, and click submit again!

Does anyone know where I would be able to make this change in the MIME:Lite module?

where to look on the server and if you think this is at least a workable compromise.

Any suggestions or other recommendations are greatly appreciated.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!