3 ms·

> Can this be fixed? For popular senders: sort-of: in your incoming mail server, substring-match the display name of the sender against popular brands, and ens

> Can this be fixed? For popular senders: sort-of: in your incoming mail server, substring-match the display name of the sender against popular brands, and ensure the actual domain matches. This works remarkably well for proper brands (FedEx et al), but breaks down when the brand name regularly occurs in "normal" names, the sending brand sends mail from all over the place, or "innocuous" impersonation takes place all the time. Like, somehow, From: "VODAFONE" <shipping-update@dpd.co.uk> is a 100% legit sender (assuming SPF and DKIM verification pass), despite both Vodafone and DPD being pretty common impersonation targets. You'd think they'd know better, but alas. So, yeah, room for improvement and such...

layer8 9mo ago
Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails. And/or, long-press or right-click on any link to inspect the linked domain.
- lightandlight 9mo ago
  I often go one step futher by appending a short random identifier, `{service}.{id}@{domain}`, to make it harder to guess (in case someone learned of my email address policy). I created a little GTK program to help: https://github.com/LightAndLight/gen-alias https://github.com/LightAndLight/gen-alias
  - layer8 9mo ago
    Yes, it’s really <f(service, rand())>.
- zahlman 9mo ago
  What fraction of people do you suppose actually have a <yourdomain> to do this with? Even some highly technically inclined people (like myself) can be entirely ignorant of the process. It's not as if consumer ISPs provide the service.
  - roboror 9mo ago
    Sub-addressing (doing tag+handle@domain.com) is supported by many email services but + may be flagged as an illegal character.
    - Terretta 9mo ago
      at least hotmail, gmail, apple's various mail, though with apple just using hide my email is that whole idea fully and beautifully automated for normies
  - layer8 9mo ago
    The process isn’t difficult and worth acquainting yourself with.
- epistasis 9mo ago
  If you don't control your own domain fully, almost all email services let you do: user+servicetag@domain.com And have it go to user@domain.com with the servicetag still in the To: field. At least, I have never encountered a problem with this.
  - cheschire 9mo ago
    And then the spammers (or other illegitimate source) just add this to their processing… ^([^@+]+)\+[^@]*(@.*)$
    - epistasis 9mo ago
      The use case here is using a unique email address to help verify the sender of the email, it's not connected to spam usage.
      - cheschire 9mo ago
        So you’re suggesting the sender use the + modifier on the from address?
        epistasis 9mo ago
        Here's the suggestion: >Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails. The user of the webservice specifies a unique email per webservice; knowledge of that unique email address serves as a hint that the email came from someone that has discovered that email address, i.e. the webservice itself.
        cheschire 9mo ago
        Right, so 99% of the time that’s a spammer that is going to use that discovered email. I updated my message to specify other illegitimate sources to cover that less than 1%
  - pests 9mo ago

layer8 9mo ago

Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails. And/or, long-press or right-click on any link to inspect the linked domain.

lightandlight 9mo ago
I often go one step futher by appending a short random identifier, `{service}.{id}@{domain}`, to make it harder to guess (in case someone learned of my email address policy). I created a little GTK program to help: https://github.com/LightAndLight/gen-alias https://github.com/LightAndLight/gen-alias
- layer8 9mo ago
  Yes, it’s really <f(service, rand())>.
zahlman 9mo ago
What fraction of people do you suppose actually have a <yourdomain> to do this with? Even some highly technically inclined people (like myself) can be entirely ignorant of the process. It's not as if consumer ISPs provide the service.
- roboror 9mo ago
  Sub-addressing (doing tag+handle@domain.com) is supported by many email services but + may be flagged as an illegal character.
  - Terretta 9mo ago
    at least hotmail, gmail, apple's various mail, though with apple just using hide my email is that whole idea fully and beautifully automated for normies
- layer8 9mo ago
  The process isn’t difficult and worth acquainting yourself with.
epistasis 9mo ago
If you don't control your own domain fully, almost all email services let you do: user+servicetag@domain.com And have it go to user@domain.com with the servicetag still in the To: field. At least, I have never encountered a problem with this.
- cheschire 9mo ago
  And then the spammers (or other illegitimate source) just add this to their processing… ^([^@+]+)\+[^@]*(@.*)$
  - epistasis 9mo ago
    The use case here is using a unique email address to help verify the sender of the email, it's not connected to spam usage.
    - cheschire 9mo ago
      So you’re suggesting the sender use the + modifier on the from address?
      - epistasis 9mo ago
        Here's the suggestion: >Use <service>@<yourdomain> as your email address when signing up, and check the To header when receiving emails. The user of the webservice specifies a unique email per webservice; knowledge of that unique email address serves as a hint that the email came from someone that has discovered that email address, i.e. the webservice itself.
        cheschire 9mo ago
        Right, so 99% of the time that’s a spammer that is going to use that discovered email. I updated my message to specify other illegitimate sources to cover that less than 1%
- pests 9mo ago