Create an account on the HP Community to personalize your profile and ask a question
12-19-2010 03:05 PM
I've seen some other threads about this type of problem, but no resolution for it so I thought I'd post to help HP to know how widespread and disappointing this is.
It appears, from reading other threads, that the eprint email system on HP's end of things is extremely finicky about what emails it will accept.
This is not acceptable. If a person's email setup, client, computer system, and ISP works fine for them for every purpose except eprint, then the problem is at HP's end of things. And this is the problem I'm having now.
We bought this printer to put at my mother's house so that the rest of the family could send photos or notes to her from their email accounts. She doesn't have the desire or computer savvy to constantly troubleshoot problems with this all.
I've spent about the last eight hours fighting through a succession of problems just getting this printer to connect to the wireless router, then connect to the eprint center, and now, with all of that seeming to work, all of my emails to the printer's email address are being rejected "bounced" with this error coming back:
"This message was created automatically by the mail system (ecelerity).
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
>>> firstname.lastname@example.org (reading confirmation): 550 5.7.1 Command rejected"
When can we expect the eprint service to work properly for ALL otherwise perfectly functional email setups on my family's various computers, ISPs, and devices?
12-19-2010 09:10 PM
I am also having the same ePrint email problem. Setting-up the 8500A has been short of a nightmare - I have spent well over 8 hours trying to get all basic features working. Documentation can be very misleading. This ePrint problem seems insurmountable from my end. I hope HP can resolve this soon.
12-21-2010 06:39 PM
Hello, I appreciate your post!
I have the same problem using a Cincinnati Bell Zoomtown Pop account. It works fine from my laptop but not from my Blackberry. This is totally unacceptable. Four technicians have spent a total of at least 6 hours proxying my computer and dinking around with the problem. They told me to call back and speak to a senior technician, but the gatekeeper that answers the phones will never allow me access to a more senior level of support.
I would steer clear of this printer if you intend to print from a Blackberry. The foreign technical support folks have no idea and if you speak English, you will struggle to understand them.HP says to call Verizon. Verizon says to call HP, Then, HP tinkers and they ultimately tell me to call Blackberry. I am getting the royal run around for buying the HP Officejet 8500A.
I have always been an HP printer user, but this is very, very, very frustrateing. After Christmas, I am going to rush this printer back to Sams!
12-27-2010 01:30 PM
I have been testing the C310A and it seems to work well with most email systems_exception is Blackberry mail.I think with BB you have to use email such as Yahoo or other webmail.
**Click Accept as Solution on a Reply that solves your issue**
***Click the Thumbs-Up button as a way to say Thanks!***
01-09-2011 02:36 PM - edited 01-09-2011 02:50 PM
I have identified and solved this problem in our environment, just today. That's the good news. The bad news is that if my solution applies to your environment, as a consumer there may not be anything you can do about it personally. I happen to be both an affected business user and an affected consumer; with an HP Eprint-enabled printer in both environments, and a mail administrator and DNS adminstrator for my company's Exchange 2007 mail organization. So I was perhaps rather uniquely situated to study this problem and to resolve it.
There is an internet standard known as SPF (referred to in the MS world as SenderID.) SPF stands for Sender Policy Framework. It involves a DNS administrator putting a TXT record in DNS that identifies, by IP address, the mail servers from which email from your domain may properly come.
When email purporting to be from your domain (email@example.com) arrives at an MX server, the MX server (if it is implementing SPF; not all do) will do a DNS lookup for your sender-side SPF record. The SPF record will say, in effect, "If this email from @mydomain.com is coming from 126.96.36.199, or an address within the 188.8.131.52/24 network, then that is a valid IP source address. If not, there's something skanky about that email's origins; it may be spam, being sent from an inappropriate soure; that is, its sender address firstname.lastname@example.org has probably been spoofed. React accordingly."
In our case, HPEPRINT's PostFix mail server was apparently finding something in our SPF/v2.0 record it did not like (we have had that record for several years and none of our email has ever bounced for this reason, so I am not sure exactly what the issue was, but...). I deleted our SPF 2.0 record and the problem with HPEPRINT vanished immediately. We have had 100% email-printing success since then, and no more "rejected" NDRs from hpeprint.com.
We still have an SPF/v1 record in our DNS, which HP's PostFix mail server apparently likes well enough. The issue in our case was with our SPF/v2.0 record, or the way PostFix was evaluating it. I'm not sure which. If our SPF record was bad, I have to wonder why we haven't had problems with any other mail domain during the last four years or more since I created that record. But anyhow..
The main moral based on our situation is: this was NOT a problem with the printer. It MAY HAVE BEEN a problem with the way hpeprint.com's mail server evaluated SPFv2 records. It MAY HAVE BEEN a problem with our SPFv2.0 record syntax or structure. But the printers in this respect are just fine. If you are sending mail through an ISP or a company email system and are not in a position to fix it, talk to your mail administrator about it and suggest he check SPF records.
The tipoff in my case was when I tried to send to hpepprint.com from the command line and got the blowback from hpeprint.com's PostFix:
"#550 5.7.1 Can't determine Purported Responsible Address."
In referring this error back to our senders, Exchange was paraphrasing as
#550 5.7.1 Command rejected
The PRA is SPF-speak.
01-25-2011 07:09 PM - last edited on 01-25-2011 10:03 PM by MrMatthew
yes isnt this just fantastic?!?
we buy this "small business" printer for our "small business", but we cant send email to it from our "small business" domain name.
We must be like the only "small business" with a website i guess...