550 5.7.1 Command rejected

Question

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:
>>> [email protected] (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?

Answer 1

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 protected]) 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 12.98.67.216, or an address within the 64.15.8.0/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 [email protected] 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.