← Back to context

Comment by layer8

4 months ago

Requiring their customers to implement SPF and DMARC as a hard technical requirement is probably bad for business. And as mentioned in TFA, they do note issues regarding SPF/DMARC in their policy.

I think in this case it's the customers of their customers, e.g. people sending emails to support@acme-corp.com. In that light requiring all emails coming into support@acme-corp.com to have SPF and DMARC is bad for business indeed, not only for Zendesk but probably also for the fictional ACME corp.

EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.

  • > EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.

    I checked my email archives and some (but not all) of the emails I've received from Zendesk have arbitrary alphanumeric ids in the Reply-To header instead of integers. Seems to depend on the company, perhaps this is a configuration issue?

  • I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.

    • The attack requires getting yourself CC’d on a support ticket. In this case to show how bad that is, it was a support ticket that had an oauth ticket to log into slack as “support@company.com”.

      3 replies →