Jump to content

Managing Director

  • Content count

  • Joined

  • Last visited

Posts posted by Managing Director

  1. The previous post was be-on-the-lookout information after over two hundred fake new accounts using blacklisted IP  addresses, were added to one customer's web site in a very short period of time. Adding a "customers_ip_address" field to the 'Customers" table and modifying "create_account.php" to save it helps us weed them out.

  2. The hundreds of fake accounts found on our web sites originated from IP addresses worldwide, but rarely from the US. We capture and monitor the IP addresses of every new account (and when an account is updated) and we check these IP addresses on DNSBL lists for abuse status. Accounts of abusers are  manually deleted. We disallowed "tell-a-friend" and modified our contact form(s) to edit every entry for reasonableness and required all fields to be reasonably populated. We resisted "CAPCHA" because customers could be lost through frustration. In addition, relying on third party software (e.g., Goggle) was a privacy and security consideration regarding both our customers and our web sites. There are user contributions that support implementing all of these measures. However, as a security matter, how we specifically implemented these modest changes to v2.3.4.1 would be inadvisable in this forum.

  3. One of our osCommerce Online Merchant v2.3.4.1 carts has processed over 16,000 orders. Shipping charges have been inexplicably absent on five orders, one as late as yesterday. There is a fingerprint left in the "orders_total" table where we found the "title" field value of 'u:' [“SELECT * FROM orders_total WHERE title = 'u:';”], rather than the valid shipping methods which are only “FedEx” and “USPS”. Has anyone else experienced this anomaly?

  4. Thanks for the information. After a bit of further research, we found that the simplest way to resolve this DMARC sendmail issue was to modify line # 522 of the class email() found in includes/classes/email.php and admin/includes/classes, to include the 5th PHP mail() argument "'-f ' . $to_addr". This would make the "Sent/From:" address match the "Return-Path:" address:

    return mail($to, $subject, $this->output, 'From: '.$from.$this->lf.implode($this->lf, $this->headers).$this->lf.implode($this->lf, $xtra_headers));

    return mail($to, $subject, $this->output, 'From: '.$from.$this->lf.implode($this->lf, $this->headers).$this->lf.implode($this->lf, $xtra_headers), '-f ' . $to_addr);

    To resolve this DMARC problem using the osCommerce SMTP option, adding the 5th PHP mail() argument to that code likely will have the same result.


  5. It is now the standard of Comcast and Charter to employ cloudmark.com to check compliance with DMARC standards which requires the "Return-Path:" address to match the "Sent/From:" address. Our shops use sendmail in osCommerce, which employs "tep_mail()" and class "email()". The problem is created by sendmail which defaults "Return-Path:" to the Linux host "Username " as Username@domain rather than Sent/From@domain. Accordingly, there needs to be an immediate fix to avoid these bounced emails never reaching our store customers because  the default "Return-Path:" fails to mirror the "Sent/From:" address.