Error from AOL: Deferred: Bad file descriptor?
in [Sendmail]
|
Prev: masquerade
Next: collect: unexpected EOM...
From: news@celticbear.com on 26 Jan 2006 10:49 Recently our mail from our e-commerce site has been rejected by AOL due to an IP block because someone was using our PHP scripts to send spam. Well, I got that fixed. But our legitimate auto-generated e-mails are getting "deferred" by AOL now with an error: Deferred: Bad file descriptor I can't find anything on their support site about this, nor Googling. Any ideas? Here's an example of an email sent by us. Best I can figure out, "file descriptor" indicates the format of the e-mail, but I'm pretty sure I have that right. Well, thanks for any suggestions or feedback! -Liam Return-Path: <g> Received: from (our domain).com (localhost [127.0.0.1])by (server name).(our domain).com (8.13.1/8.13.1) with ESMTP id k0PNeuPW006683for <(aol username)@AOL.COM>; Wed, 25 Jan 2006 17:40:56 -0600 Full-Name: Apache Received: (from apache(a)localhost)by (our domain name).com (8.13.1/8.13.1/Submit) id k0PNeueJ006679;Wed, 25 Jan 2006 17:40:56 -0600 Date: Wed, 25 Jan 2006 17:40:56 -0600 Message-Id: <200601252340.k0PNeueJ006679@(our domain name).com> To: (aol username)@AOL.COM Subject: Cards - ORDER 37329 From: Printing.Order@(our domain name).com Reply-To: customerservice@(our domain name).com Content-type: text/html; charset=iso-8859-1 <HTML> <HEAD> </HEAD> <BODY BGCOLOR="white"><center><b>STUDIO DETAILS</b><br> <table width="450" cellspacing="0" cellpadding="0" border="0"> <tr> <td width="150" align="right">Account ID: </td> <td width="300" align="left">bctcom</td> </tr> <tr> <td width="150" align="right">Company: </td> <td width="300" align="left">(Company name)</td> </tr> <tr> <td width="150" align="right">Folder: </td> <td width="300" align="left">/bct/</td> </tr> </table><br> <b>ORDER DETAILS</b><br> <table width="300" cellspacing="0" cellpadding="0" border="0"> <tr> <td width="150" align="right">Order #: </td> <td width="150" align="left">37329</td> </tr> <tr> <td width="150" align="right">Total Charge: </td> <td width="150" align="left">$69.00</td> etc etc...
From: Sadara on 26 Jan 2006 12:03 news(a)celticbear.com wrote: > I can't find anything on their support site about this, nor Googling. > Any ideas? try googling again. it works for me.
From: Gordon Burditt on 26 Jan 2006 12:18 >Recently our mail from our e-commerce site has been rejected by AOL due >to an IP block because someone was using our PHP scripts to send spam. >Well, I got that fixed. >But our legitimate auto-generated e-mails are getting "deferred" by AOL >now with an error: >Deferred: Bad file descriptor This is either a problem with your procedure for SENDING the mail, or a configuration problem at AOL that you can't fix. Are you opening a SMTP connection to AOL's servers DIRECTLY from PHP? I doubt it. It's probably a problem between your PHP and your sendmail or whatever you are using to send mail. Of course, some hosts put out misleading error messages. I doubt AOL would do this because of the support problems it would cause. But I have seen things like: 550 No such user means the email address doesn't exist. 550 No such user. means "you've been banned for spamming". 550 no such user means "you've been banned for sending viruses". 550 no such User means "you've been banned due to complaints from customers" >I can't find anything on their support site about this, nor Googling. >Any ideas? It's likely not their problem. >Here's an example of an email sent by us. Best I can figure out, "file >descriptor" indicates the format of the e-mail, but I'm pretty sure I >have that right. "file descriptor" represents an open file (Windows might call it a "handle"). It's a much more basic problem than nitpicking about headers in email. >Return-Path: <?g> That return-path looks pretty darn wierd. >Received: from (our domain).com (localhost [127.0.0.1])by (server >name).(our domain).com (8.13.1/8.13.1) with ESMTP id k0PNeuPW006683for ><(aol username)@AOL.COM>; Wed, 25 Jan 2006 17:40:56 -0600 >Full-Name: Apache >Received: (from apache(a)localhost)by (our domain name).com >(8.13.1/8.13.1/Submit) id k0PNeueJ006679;Wed, 25 Jan 2006 17:40:56 >-0600 >Date: Wed, 25 Jan 2006 17:40:56 -0600 >Message-Id: <200601252340.k0PNeueJ006679@(our domain name).com> >To: (aol username)@AOL.COM >Subject: Cards - ORDER 37329 >From: Printing.Order@(our domain name).com Does the email address Printing.Order@(our domain name).com actually accept email? There are quite a few hosts that will reject an email if it doesn't. >Reply-To: customerservice@(our domain name).com >Content-type: text/html; charset=iso-8859-1 > > ><HTML> > <HEAD> > </HEAD> > <BODY BGCOLOR="white"><center><b>STUDIO DETAILS</b><br> > <table width="450" cellspacing="0" cellpadding="0" border="0"> > <tr> > <td width="150" align="right">Account ID: </td> > > <td width="300" align="left">bctcom</td> > </tr> > <tr> > <td width="150" align="right">Company: </td> > <td width="300" align="left">(Company name)</td> > </tr> > <tr> > > <td width="150" align="right">Folder: </td> > <td width="300" align="left">/bct/</td> > </tr> > </table><br> > <b>ORDER DETAILS</b><br> > <table width="300" cellspacing="0" cellpadding="0" border="0"> > <tr> > > <td width="150" align="right">Order #: </td> > <td width="150" align="left">37329</td> > </tr> > <tr> > <td width="150" align="right">Total Charge: </td> > <td width="150" align="left">$69.00</td> > >etc etc... > Gordon L. Burditt
From: news@celticbear.com on 26 Jan 2006 12:28 Gordon Burditt wrote: > >Recently our mail from our e-commerce site has been rejected by AOL due > >to an IP block because someone was using our PHP scripts to send spam. > >Well, I got that fixed. > >But our legitimate auto-generated e-mails are getting "deferred" by AOL > >now with an error: > >Deferred: Bad file descriptor > > This is either a problem with your procedure for SENDING the mail, > or a configuration problem at AOL that you can't fix. Are you > opening a SMTP connection to AOL's servers DIRECTLY from PHP? > I doubt it. It's probably a problem between your PHP and your > sendmail or whatever you are using to send mail. > Uhm.. nooo... I don't think so. I'm using the mail() function in PHP. So I guess PHP does some funky stuff and then opens the connection. To troubleshoot I'll investigate how to open an SMTP connection directly. (If I recall, a few years ago when I was learning ASP, I think that's the way it had to be done using DONTS(sp) objects....) [..] > > >Here's an example of an email sent by us. Best I can figure out, "file > >descriptor" indicates the format of the e-mail, but I'm pretty sure I > >have that right. > > "file descriptor" represents an open file (Windows might call it a "handle"). > It's a much more basic problem than nitpicking about headers in email. > > >Return-Path: <g> > That return-path looks pretty darn wierd. > Yeah. I copied the header off the Webmin GUI for e-mail cache, and that "ng" is actually a little icon that I think represents a binary or some non-ascii character. I saw that and wondered about that. But when I view the e-mail through a client like Thunderbird, it says: Return-Path: <apache@(my domain name).com> So I don't get why it would be non-ascii through Webmin but OK in a client. 2ndly, and I have no idea if this is related, I actually define Return-Path in the header variable in the PHP code, and it's supposed to be <Printing.Order@(our domain name).com> but that seems to be ignored. Odd. [..] > >Subject: Cards - ORDER 37329 > >From: Printing.Order@(our domain name).com > > Does the email address Printing.Order@(our domain name).com actually > accept email? There are quite a few hosts that will reject an email > if it doesn't. > Yeah, I made sure that's a legit e-mail address. Although it forwards to our customerservice account. But you can email that address directly. Thanks for the feedback! I'll look into the direct SMTP connection and digging deeper into the Return-Path. -Liam
From: Claus Aßmann on 26 Jan 2006 12:33
news(a)celticbear.com wrote: > Gordon Burditt wrote: > > >Return-Path: <?g> > > That return-path looks pretty darn wierd. It's a macro and those are encoded as 8 bit characters. About the original error message: upgrade to 8.13.5 and see whether the problem goes away, there have been some fixes for problems like this (check the release notes). -- Note: please read the netiquette before posting. I will almost never reply to top-postings which include a full copy of the previous article(s) at the end because it's annoying, shows that the poster is too lazy to trim his article, and it's wasting the time of all readers. |