Ask HN: Email provider allows sender spoofing, is that okay?

4 points by tlynchpin 7 years ago | 3 comments

I have been a long time customer of a local, long running and well respected internet service provider.

I recently found that they allow email sender spoofing. I am in discussion with them to determine the details but so far the facts are my address was spoofed and they said everything is working as intended. I did not expect this, especially given this provider's reputation. I'm surprised, shocked, and upset.

My question: is it unreasonable of me to expect my email provider does not allow email sender fraud?

Edit: I appreciate the attention and I'm sorry I was not specific.

The provider accepted and delivered a message that originated outside of their domain where the sender and recipient is in their domain.

In other words, provider is Example.com, my address is tim@example.com, they delivered a message from outside of their network that had tim@example.com as sender and recipient.

pwg 7 years ago |

> My question: is it unreasonable of me to expect my email provider does not allow email sender fraud?

Yes, because you expect something that is not possible given how SMTP email is designed. Sender spoofing is trivial to perform and unless the recipient has sufficient technical knowledge to detect the spoof (they don't need much technical knowledge, but they do need some) the recipient will not know one from another.

You validate that your emails did in fact get sent by you by GPG (https://www.gnupg.org/) signing them when you send them, and having the recipients know enough to be able to verify the GPG signatures.

akerl_ 7 years ago | |

Wouldn’t the spoofing issue be resolved by having SPF records, the receiving mail providers validating SPF, and the origin mail provider requiring auth for their SMTP server?

That would seem to ensure the sender without requiring end users to manage GPG keys or validate signatures.

LinuxBender 7 years ago |

In my opinion, it is reasonable to expect them to either validate you own the domain you are sending from, or to handle misuse aggressively. Perhaps they painted themselves into a corner in their infrastructure design and lack good engineers to resolve this? They might not admit this.