>> >Recently our mail from our e-commerce site has been rejected by AOL due[color=blue][color=green][color=darkred]
>> >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[/color]
>>
>> 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.
>>[/color]
>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.[/color]
Usually PHP hands off the mail to the local sendmail, or another
local (network) mail server. You cannot just send all your mail
to AOL's mail server (unless you're an AOL customer) - you only
send stuff there that is supposed to go to AOL. Spammers have
abused that so any server that allows relaying like that for anyone
gets itself banned. PHP does not try to perform the full functions
of a mail server: looking up MX records and figuring where to send
mail, retrying mail in case of down servers, sending bounce messages,
etc. And it probably shouldn't.
[color=blue]
>To troubleshoot I'll investigate how to open an SMTP connection
>directly.[/color]
You probably should NOT be trying to do this for production work.
Let your mail server (not PHP code) or your ISP's mail server handle
it. A mail server needs to run as a daemon or be periodically run
from cron, not occasionally from a web server.
[color=blue]
>(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....)
>
>[=2E.][color=green]
>>[color=darkred]
>> >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.[/color]
>>
>> "file descriptor" represents an open file (Windows might call it a "handl=[/color]
>e").[color=green]
>> It's a much more basic problem than nitpicking about headers in email.
>>[color=darkred]
>> >Return-Path: <=81g>[/color]
>> That return-path looks pretty darn wierd.
>>[/color]
>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.[/color]
Setting the envelope-sender may be restricted by the local sendmail.
[color=blue]
>
>[=2E.][color=green][color=darkred]
>> >Subject: Cards - ORDER 37329
>> >From: Printing.Order@(our domain name).com[/color]
>>
>> 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.
>>[/color]
>
>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
>[/color]
Gordon L. Burditt
