In the 1980s one of my principal responsibilities was enabling communications between retail point-of-sale systems and the host computer where we processed those transactions. Communications protocols were many and varied, and I had to figure out their nuances and get the registers to talk to the hosts. Success was most often achieved when, after sending a message to the remote system, I received back a message called an Ack, an acknowledgement that the message had been received successfully.
In recent attempts at communication (via email, mostly), I've been finding that the receiving party doesn't feel the overwhelming need to let me know that the communication was received, and this is extremely frustrating to me. I have taken to asking questions that need to be answered, just to ensure that the message is being delivered. (I really already know the answer, but it gets the respondent to acknowledge the message.)
Communication is key to success, whether it's a project, a business relationship (or any type of relationship, really), and without two-way communication assumptions can be made that could cause that relationship, or database servers, to break down, and that's generally a bad thing. I try to avoid bad things.
So really, send an Ack. It's not hard and lets the sender know you're there, and the project is still on track.