Email servers often do not understand what the .eps file format is - specifically any binary data. In some cases the server sees them as "executable" files because of internal binary data and due to this the server will often scan the file for viruses and in the process break the file.
In order to email an eps file, the best practice is to always compress the .eps into an archive, such as a .zip file. Then email the .zip file rather than the raw .eps file.
There's nothing you can do to fix this corruption when it occurs. If a client sent you a raw .eps file and you can't open it or it opens with errors or missing data you can only request a new file and ask that it be compressed before emailing it.
Note it appears to only be emailing that is an issue. Services such as DropBox or Hightail don't have a problem with .eps files. It's email servers that don't fully understand the format and damage it in an effort to protect users.
This issue has a great deal to do with data encoding on the client side. Data can be sent as UU, Binary, or Base64. Many desktop email clients have a difficult time with binary data and often break EPS files when they are sent in binary form. Many desktop email clients will also allow a user to specific the data encoding, however many users are completely unaware of how, why, when, or where to alter this data encoding setting. If they were, they could simply specify UU or Base64 encoding and the eps files should transport without issues. Web mail clients typically default to Base64 encoding for files. Base64 isn't generally any issue with EPS files. So, in general terms, using a web-mail provider such as Gmail in a browser doesn't show the issue.
In my own experience, only about 1 in 50 .eps files actually makes it through email unscathed.