Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

AOL emails


peterr

Recommended Posts

Posted

Received this today, it will affect some osCommerce sites.

 

We have noticed a change in the way that AOL is filtering their email and we want to make you aware of the situation because it might very well be directly affecting you or your clients.

 

AOL has seen fit to filter any emails that are generated by a PHP script. So, if you have a shopping cart or a forum that is written using PHP (which is most of them) and that script generates an email to a customer who has an @aol.com email address, they will most likely not receive it. This would also include PHP mail forms with AOL destinations.

 

There is very little that can be done for this. IF your script has SMTP support, I would encourage you to switch over to that method of sending mail as that should allow the mail to go through. Many scripts do not have this option built in, however.

 

If you have an AOL account and t his disturbs you, then I encourage you to call and voice your displeasure. If you have site visitors and they contact you regarding the lack of emails, then I suggest you first find out if they have an AOL account and if so, then encouraage them to complain as well.

Posted

I wouldn't worry too much about this. First of all, AOL (or anyone else) cannot determine the difference between a script generated email and an email typed up in Outlook. As long as the mail format is correct there is no difference between these messages. Also, the SMTP comment makes no sense. All Internet email is sent via SMTP, so I'm not sure what the person is trying to say. Best way to deal with things like this is to actually test it. Create yourself test accounts and see if you get the messages. Good practice is to fully test your site regularly to make sure everything is functional.

Posted
First of all, AOL (or anyone else) cannot determine the difference between a script generated email and an email typed up in Outlook. As long as the mail format is correct there is no difference between these messages.

 

There is a great deal of information in email headers. One 'set' of headers is the "X-Mailer", which will show if the email is sourced from Outlook, Pegasus mail, phpmailer,etc,etc.

 

Even I can tell is the email is generated in Outlook or a script. :D

Posted
There is a great deal of information in email headers. One 'set' of headers is the "X-Mailer", which will show if the email is sourced from Outlook, Pegasus mail, phpmailer,etc,etc.

 

Even I can tell is the email is generated in Outlook or a script. :D

 

Exactly. For example:

 

Order confirmation email from store:

 

X-Mailer: osCommerce Mailer

 

Email sent from a customer using Outlook Express:

 

X-Mailer: Microsoft Outlook Express 6.00.2800.1106

Rule #1: Without exception, backup your database and files before making any changes to your files or database.

Rule #2: Make sure there are no exceptions to Rule #1.

Posted

That is interesting. The general line of thought at the one forum discussion is that AOL is only blocking emails from the apache user nobody. The return-path in my order confirmation emails is set to the store manager email address and they are still going through to AOL just fine. I wonder if this would only affect osc users that left the store owner email blank?

Rule #1: Without exception, backup your database and files before making any changes to your files or database.

Rule #2: Make sure there are no exceptions to Rule #1.

Posted
The general line of thought at the one forum discussion is that AOL is only blocking emails from the apache user nobody. The return-path in my order confirmation emails is set to the store manager email address and they are still going through to AOL just fine. I wonder if this would only affect osc users that left the store owner email blank?

 

The first post in this thread , states

 

Just an FYI: AOL mail servers are now rejecting all emails with a return path of anything like nobody@, httpd@, apache@, sender@, www@, root@, etc...

 

so it would seem to be more than just user 'nobody'

 

I don't think leaving the store owner email blank will affect it, from memory, the return path was always a server configuration, and _most_ (Apache) servers are setup to put 'nobody' as the user.

 

The CPanel thread suggested installing Phpsuexec, then one person replied doing that will break osC, and another reply then stated it will work ??

 

(... a bit annoying not being able to read the CPanel threads without registering though).

 

HTH

Posted
so it would seem to be more than just user 'nobody'

 

I don't think leaving the store owner email blank will affect it, from memory, the return path was always a server configuration, and _most_ (Apache) servers are setup to put 'nobody' as the user.

 

Well, another thought might be in the differences between sendmail and qmail. My server uses qmail instead of sendmail. For example if they are filtering using the entry from Message-ID rather than Return-Path, perhaps sendmail enters [email protected] whereas qmail enters [email protected] . In which case, as soon as AOL figures that out they will probably add qmail to their list

 

Irregardless, here is what the email header of one of my order confirmation emails looks like and they are currently going through to AOL users just fine (names changed to protect the innocent):

 

Return-Path: <[email protected]>

Delivered-To: [email protected]

Received: (qmail 184396 invoked by uid 4808); 19 Dec 2005 23:03:33 -0600

Date: 19 Dec 2005 23:03:33 -0600

Message-ID: <[email protected]>

To: Customer Name [email protected]

Subject: Your order summary from My Store Name

From: "My Store Name" <[email protected]>

MIME-Version: 1.0

X-Mailer: osCommerce Mailer

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Rule #1: Without exception, backup your database and files before making any changes to your files or database.

Rule #2: Make sure there are no exceptions to Rule #1.

Posted

Okay, it seems the server you use is setup correctly. I checked one osC site, and the 'Return-Path:' had one of the usernames that AOL doesn't like, that was from a (test) order, so it would be site specific.

 

Of interest is the email header used for osC topic replies:

 

Return-path: <[email protected]>

 

so, .... that username _should_ be okay.

 

If you ran a phpinfo() on your website, I'd say that 'sales@.....' would be there, because none of the standard osC source code modifies the 'Return-Path:'

 

Peter

Posted
Okay, it seems the server you use is setup correctly. I checked one osC site, and the 'Return-Path:' had one of the usernames that AOL doesn't like, that was from a (test) order, so it would be site specific.

 

Of interest is the email header used for osC topic replies:

 

Return-path: <[email protected]>

 

so, .... that username _should_ be okay.

 

If you ran a phpinfo() on your website, I'd say that 'sales@.....' would be there, because none of the standard osC source code modifies the 'Return-Path:'

 

Peter

 

So what your test proves is that the httpd.conf service needs to be configured to run as a user other than "nobody"? Just want to make sure I understand the test you did on your store.... my store's order status update also generates emails with a Return-path: of [email protected] which is being blocked by AOL at the moment (or at least throttled...).

Posted
So what your test proves is that the httpd.conf service needs to be configured to run as a user other than "nobody"? Just want to make sure I understand the test you did on your store.... my store's order status update also generates emails with a Return-path: of [email protected] which is being blocked by AOL at the moment (or at least throttled...).

 

My 'test' was looking at some osC generated email headers from quite a few months ago, from an order, so it may be more prudent to take note of what GraphicsGuy has setup.

 

But in principle I would say the Apache config., as you have stated, is what needs to be changed. Something other than the 6 usernames mentioned here.

 

Configuring it to the same as the osC 'store owner' email address would most likely be what most people would do in this situation.

 

If I run phpinfo() on a website, the Apache user is 'nobody', and unless a PHP,Perl,etc script actually modifies the headers before the email is sent from the script, then the 'Return-Path:' will always be '[email protected]'

Posted
My 'test' was looking at some osC generated email headers from quite a few months ago, from an order, so it may be more prudent to take note of what GraphicsGuy has setup.

 

But in principle I would say the Apache config., as you have stated, is what needs to be changed. Something other than the 6 usernames mentioned here.

 

Configuring it to the same as the osC 'store owner' email address would most likely be what most people would do in this situation.

 

If I run phpinfo() on a website, the Apache user is 'nobody', and unless a PHP,Perl,etc script actually modifies the headers before the email is sent from the script, then the 'Return-Path:' will always be '[email protected]'

 

yea I'm using Exim on my server so seems like the path of least resistance would be to mod apache to a more suitable name.

 

just tired of getting emails from AOL users asking for an update on their order.

 

This change at AOHELL also seems to impact users from the netscape.net domain and the aim.com. at least it appears that way on the surface - would require more digging to validate though....

Posted
just tired of getting emails from AOL users asking for an update on their order.

 

If you didn't want to modify your Apache config, you can (fairly) easily parse the email headers with osC, my memory is not good, but I _think_ the extra parameter that _can_ be passed to the PHP mail() function is 'empty' in the osC functions/classes.

 

You probably know how to do it, but I just found a script where I had tested changing the 'Return-Path:'

 

<?php

$to = "[email protected]";
$from = "[email protected]";
$cc = "[email protected]";
$bcc = "[email protected]";

$subject = "E-Mail Subject";
$message .= "E-Mail Message\n";
$message .= "More E-Mail Message\n";

mail( $to, $subject, $message, "Return-Path: $from\nFrom: $from\nCc: $cc\nBcc: $bcc\n" )

?>

 

HTH

Posted
If you didn't want to modify your Apache config, you can (fairly) easily parse the email headers with osC, my memory is not good, but I _think_ the extra parameter that _can_ be passed to the PHP mail() function is 'empty' in the osC functions/classes.

 

You probably know how to do it, but I just found a script where I had tested changing the 'Return-Path:'

 

<?php

$to = "[email protected]";
$from = "[email protected]";
$cc = "[email protected]";
$bcc = "[email protected]";

$subject = "E-Mail Subject";
$message .= "E-Mail Message\n";
$message .= "More E-Mail Message\n";

mail( $to, $subject, $message, "Return-Path: $from\nFrom: $from\nCc: $cc\nBcc: $bcc\n" )

?>

 

HTH

 

 

yea I googled this issue and looks like this horse has been hit before....found threads going back to 2002 on the subject (Not specifically AOHELL, but tweaking the return-path: values) There are several suggestions out ther similar to yours. I guess some testing is in order as I hacked up the email class already and it did not yield the results I was looking for.

 

Looking at your code above, I do believe the headers and extra headers variables are the last variables passed... I was specifically going to look at the send() function in the /includes/classes/email.php file....

Posted

From another osC thread just recently .........

 

Catalog/includes/classes/email.php file lines 519-523 are coded as follows:

 

if (EMAIL_TRANSPORT == 'smtp') {
return mail($to_addr, $subject, $this->output, 'From: ' . $from . $this->lf . 'To: ' . $to . $this->lf . implode($this->lf, $this->headers) . $this->lf . implode($this->lf, $xtra_headers));
} else {
return mail($to, $subject, $this->output, 'From: '.$from.$this->lf.implode($this->lf, $this->headers).$this->lf.implode($this->lf, $xtra_headers));
}

 

so the variable lokks like it is $xtra_headers.

 

In the source code I have, the whole 'extra headers' thing is between lines 481 to 503 though.

Posted

All things being equal, it would appear the send() function is called within the tep_mail() function, line 975 of /catalog/includes/functions/general.php

 

$message->send($to_name, $to_email_address, $from_email_name, $from_email_address, $email_subject);

 

Five parms are parsed, and the send() function in /catalog/includes/classes/email.php does include the extra one, the sixth parm, so at a bit of a guess, if line (say) two lines are added before line 975 is modified as follows:

 

$from = "[email protected]";
$headers = "Return-Path: $from\n";

 

and then line 975 modified to .............

 

$message->send($to_name, $to_email_address, $from_email_name, $from_email_address, $email_subject,$headers);

 

........ should work.

Posted

they aren't just blocking scripts.

 

if some aol member submits your website, or even someone else on your server (completely unrelated to you or your site) as a "spam", your entire server ip/domain will be blocked. (i'm not completely sure of the process, but that about sums the difficulty of it from what i've heard...)

 

i've been having this problem for months and even my host has contacted aol about it to remove the ban.

 

no luck yet. any customers on aol do not receive a SINGLE email from me.

 

way to go aol

Posted
they aren't just blocking scripts.

 

if some aol member submits your website, or even someone else on your server (completely unrelated to you or your site) as a "spam", your entire server ip/domain will be blocked. (i'm not completely sure of the process, but that about sums the difficulty of it from what i've heard...)

 

i've been having this problem for months and even my host has contacted aol about it to remove the ban.

 

no luck yet. any customers on aol do not receive a SINGLE email from me.

 

way to go aol

 

Yes, that is called a blocklist and many ISP's use them. It does take a few spam reports, last time I knew I think it was 5 reports got your IP blocked for a week. To get a semi-permanent block, either somebody on the server was spamming or the host hadn't properly secured the mail server and it got on a block list of "open relays". Either of those can actually get the entire subnet on a block list.

 

A good place to find out if your IP is on a blocklist is to use the Spam Database Lookup tool at dnsstuff.com (free). It looks up your IP in about 150 spam and open relay databases (including AOL) and reports the type and level of block.

Rule #1: Without exception, backup your database and files before making any changes to your files or database.

Rule #2: Make sure there are no exceptions to Rule #1.

Posted

False spam notices were exactly why I did 2 things:

1) moved off of my then-web hosting company when they wouldn't work with me

2) switched to a double opt-in system

 

I did learn some interesting things, though, like in some of the ways that an AOL user can get email, the "report spam" button is very close to the "delete" button.

 

Also, if friend1 sends email to friend2, who have been corresponding for years, and one day friend1 (on aol) decides to mark friend2's email as spam, AOL may warn friend2's hosting company with a blacklist warning. Friend2 may contact his hosting company, who has of course suspended his account without warning (some companies will do this), shutting down whatever was running, being sold, being used for research, whatever, but they will tell him that there is nothing they can do about it. They may enable the account again, but a 2nd warning from AOL will probably result in that user's account being terminated. The hosting company doesn't want their IPs blacklisted. My hosting company at the time actually told me that I should remove all @aol.com addresses from my mailing list. I told them that my @aol.com customers were worth more to me than my $20/month hosting account, and went elsewhere.

 

After switching to a better hosting company, and going with a double opt-in system, I've had absolutely no problems.

 

-jared

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...