Upwork Inc. violates its own DMARC and SPF policy
8 points
10 hours ago
| 4 comments
| HN
I am not sure whether it happens on all outgoing emails or only on some of them. The SPF policy for upwork.com specifies that mail.clinchtalent.com and all IP addresses that are listed by spf.mandrillapp.com are allowed to send email on behalf of upwork.com

However, at least some (if not all) of the system emails that are generated and sent by the Upwork marketplace go through MailGun - and their IP addresses are missing from the SPF policy for upwork.com Additionally, the DMARC policy for upwork.com is set to "strict" - which means that if the SPF check fails then all RFC-compliant SMTP servers should reject the message.

I raised a support ticket and clearly explained the situation. The support agent admitted that he is not trained on such things and does not understand the overly technical part of my explanations (including screenshots and logs) - so I naturally asked for escalation to someone who is more qualified.

Quite expectedly, my request was ignored and we continued our conversation back and forth. I tried to explain the security and deliverability implications of such DNS misconfiguration for the Upwork company - and my words were again ignored.

Another support agent stepped-in (perhaps another shift) and we are back on step 1 - the situation is better than chatting with an AI but apparently not so much if unqualified staff refuses to transfer the ball to their more qualified colleagues.

I can understand that engineers do not want to be bothered with trivial things. But when the first line of support does not understand what I am talking about and we are exchanging a dozen of messages while a mid-level engineer would have got the thing already on step 1 - all the consequences go to the company first and then on its customers.

winstonwinston
21 minutes ago
[-]
> Additionally, the DMARC policy for upwork.com is set to "strict" - which means that if the SPF check fails then all RFC-compliant SMTP servers should reject the message.

There is no “strict” policy. DMARC policy can be one of the following p= {none, quarantine, reject}.

The receiver decides if it wants to apply published DMARC policy for unauthenticated mail. What problem are you seeing exactly?

Remember both SPF and DKIM are used for policy evaluation.

reply
avian
1 hour ago
[-]
No idea about Upwork, but I had about the same situation about some other company sending me mail I cared about for a reason and their mail was not getting delivered to me because their DMARC check was failing.

They said "thanks, we'll look into it" and kept sending broken mail for years.

My guess is if you're a big enough player Google learns to ignore your broken DMARC config or somebody knows somebody on the inside who can add an exception. And then your mail gets delivered to @gmail.com just fine and that means it's working and wtf is this guy complaining about.

reply
KomoD
9 hours ago
[-]
> The SPF policy for upwork.com specifies that mail.clinchtalent.com and all IP addresses that are listed by spf.mandrillapp.com are allowed to send email on behalf of upwork.com

No, it also lists Valimail as being able to make decisions on SPF. That's what the "include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email" part is.

https://support.valimail.com/en/articles/8466461-valimail-sp...

reply
tmcdos
9 hours ago
[-]
According to https://tools.sendmarc.com/spf-policy-test/upwork.com/198.24... v5142.v530814cf.use4.send.mailgun.net or c66.c5341538.usw1.send.mailgun.net are not allowed to send emails on behalf of upwork.com You can also check through https://spf.access.nu/ or https://dmarcian.com/spf-survey/ that IPs belonging to MailGun are not allowed to send emails for upwork.com
reply
KomoD
8 hours ago
[-]
Those tools aren't using the macro which means they are not following the RFC, stop using crappy online tools and wasting people's time.

You can read about it here: https://datatracker.ietf.org/doc/html/rfc7208#section-7

dig +short TXT "159.112.254.142._ip.v5142.v530814cf.use4.send.mailgun.net._ehlo.upwork.com._spf.vali.email"

"v=spf1 include:mailgun.org -all"

--

dig +short TXT mailgun.org

"v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all"

--

dig +short TXT _spf.mailgun.org

"v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all"

--

dig +short TXT _spf2.mailgun.org

"v=spf1 ip4:104.130.122.0/23 ip4:146.20.112.0/26 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ip4:143.55.232.0/22 ip4:159.112.240.0/20 ip4:198.244.48.0/20 ip4:204.220.168.0/21 ip4:204.220.176.0/20 ~all"

And there's 159.112.240.0/20.

--

The SPF lookup limit is 10 which means that this way of doing it is totally valid.

And here's where you can read about the lookup limit: https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

reply
tmcdos
7 hours ago
[-]
Got it. Thanks and apologies.
reply
tmcdos
9 hours ago
[-]
After some investigation, it looks like only mailgun.org is declared in ValiMail but not mailgun.net, e.g. a DNS query for 198.244.56.66._ip.c66.c5341538.usw1.send.mailgun.net._ehlo.upwork.com._spf.vali.email returns "v=spf1 include:mailgun.org -all"
reply