3 ms·
Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.
by layer8 2y ago
Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.
- cjbprime 2y agoThat doesn't sound right. Aren't these @zendesk.com addresses?
- layer8 2y agoThe spoofed addresses were support@company.com, is my understanding. Zendesk is very well aware of SPF/DMARC, from their support pages.
- Thorrez 2y agoThe spoofed address was appleid@id.apple.com . support+id@company.com was the to address, not the from address. https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#reproduction-steps-apple---zendesk---slack https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
- Thorrez 2y agoNo, it's spoofed appleid@id.apple.com addresses. But you are correct that it's not customer SPF/DMARC configuration that's the problem.
- Aachen 2y agoThey could make the ticket IDs unpredictable so you can't subscribe yourself to any existing ticket by sending it an email
- aftbit 2y agoZendesk could refuse to allow "ticket collaboration" if customers had a missing or insufficiently secure SPF/DMARC configuration, or at least make customers check a box that says "Tickets may leak their contents to anyone who can send emails".