Upwork Inc. 违反了其自身的 DMARC 和 SPF 政策。
我不确定这是否发生在所有外发邮件上，还是仅仅是其中一些。upwork.com的SPF策略规定，mail.clinchtalent.com及所有由spf.mandrillapp.com列出的IP地址被允许代表upwork.com发送邮件。
然而，至少一些（如果不是全部）由Upwork市场生成并发送的系统邮件是通过MailGun发送的，而它们的IP地址在upwork.com的SPF策略中缺失。此外，upwork.com的DMARC策略设置为“严格”，这意味着如果SPF检查失败，所有符合RFC标准的SMTP服务器都应该拒绝该邮件。
我提交了一个支持工单，并清楚地解释了情况。支持人员承认他没有接受过相关培训，对我解释中的过于技术性的部分（包括截图和日志）并不理解，因此我自然请求将问题升级给更有资格的人处理。
可以预料，我的请求被忽视了，我们的对话反复进行。我试图解释这种DNS错误配置对Upwork公司的安全性和邮件送达性的影响，但我的话再次被忽视。
另一位支持人员介入（可能是换班了），我们又回到了第一步——这种情况比与AI聊天要好，但显然如果不合格的员工拒绝将问题转交给更有资格的同事，情况也不会好到哪里去。
我可以理解工程师们不想被琐事打扰。但当第一线支持人员不理解我在说什么，而我们交换了十几条消息时，一个中级工程师早就能在第一步解决问题——所有后果首先会影响公司，然后再影响其客户。
查看原文
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<p>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.<p>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.<p>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.<p>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.<p>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.