So this is a random grumble about hosting your own email. I’ve been doing it for over ten years. I own a server with a static IP, for which the ISP has refused to fix the reverse DNS lookup, but that’s another story (it points to a non-existing domain).
Anyway, for the last 3 weeks I tried to submit a support case to DJI.
My SPF & DMARC config
First I want to show you my config. Basically, it’s as simple as it gets. For SPF, only one IP (+a and mx records) are allowed to send email, every other server should be rejected (‘-all’). For DMARC, same config applies, except that I suggest “quarantine” instead of reject. (don’t ask me why, I don’t remember).
$ dig +short TXT sepio.pl "v=spf1 a mx ip4:185.14.73.206 -all" $ dig +short txt _dmarc.sepio.pl "v=DMARC1\; p=quarantine\; rua=mailto:[email protected]\; ruf=mailto:[email protected]\; fo=1\; adkim=r\; aspf=r\; pct=100\; rf=afrf\; ri=86400" $ dig +short TXT mail._domainkey.sepio.pl "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDipOSn3i5c7ntvK+7Xxzr9Ph8+hdtSprKmSWx9bidUVo183ygsAT7VZ7Ue02Ivt2agN2OGISHOdxIz38wFrdPYNrb27/U7C0PjelFvkAohxjAImAFEWjOeoZTYipnia1ucSU+fir8A+l2lxE1tisdxLH4KqKaSqBe6SD507rayLwIDAQAB"
| Tag | TagValue | Name | Description |
|---|---|---|---|
| v | DMARC1 | Version | Identifies the record retrieved as a DMARC record. It must be the first tag in the list. |
| p | quarantine | Policy | Policy to apply to email that fails the DMARC test. Valid values can be ‘none’, ‘quarantine’, or ‘reject’. |
| rua | mailto:[email protected] | Receivers | Addresses to which aggregate feedback is to be sent. Comma separated plain-text list of DMARC URIs. |
| ruf | mailto:[email protected] | Forensic Receivers | Addresses to which message-specific failure information is to be reported. Comma separated plain-text list of DMARC URIs. |
| fo | 1 | Forensic Reporting | Provides requested options for generation of failure reports. Valid values are any combination of characters ’01ds’ seperated by ‘:’. |
| adkim | r | Alignment Mode DKIM | Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. Valid values can be ‘r’ (relaxed) or ‘s’ (strict mode). |
| aspf | r | Alignment Mode SPF | Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. Valid values can be ‘r’ (relaxed) or ‘s’ (strict mode). |
| pct | 100 | Percentage | Percentage of messages from the Domain Owner’s mail stream to which the DMARC policy is to be applied. Valid value is an integer between 0 to 100. |
| rf | afrf | Forensic Format | Format to be used for message-specific failure reports. Valid values are ‘afrf’ and ‘iodef’. |
| ri | 86400 | Reporting Interval | Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. Valid value is a 32-bit unsigned integer. |
Attempt #1 – Web Form
https://www.dji.com/support offers you a way to send an email regarding the product and asking for support. Unsurprisingly, it (probably) puts your email address on the envelope – which means that they try to impersonate you (to some extent). It’s no surprise that the support case is never created, and that at some point you will get a rejection email (at least that).
Attemp #2 – send an email directly
So I emailed [email protected] directly. Some days later I get a DMARC Aggregate Report again (“Report Domain: sepio.pl Submitter: dji.com Report-ID:”). This is what it states:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<version>1.0</version>
<report_metadata>
<org_name>dji.com</org_name>
<email>[email protected]</email>
<extra_contact_info>[email protected]</extra_contact_info>
<report_id>[email protected]</report_id>
<date_range>
<begin>1620057603</begin>
<end>1620144003</end>
</date_range>
</report_metadata>
<policy_published>
<domain>sepio.pl</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp></sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>166.78.69.236</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>sepio.pl</header_from>
<envelope_from>mailer-www.dji.com</envelope_from>
</identifiers>
<auth_results>
<spf>
<domain>mailer-www.dji.com</domain>
<scope>mfrom</scope>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>DJI server seems to be “proxying” the email via 166.78.69.236 and tries to impersonate your email. But then they later validate DKIM and SPF, and since 166.78.69.236 is NOT my email server, both of those policies fail.
It also seems like DKIM is failing, which I assume is failing since the email was originally signed, and it seems that signature is somehow becoming malformed (or removed alltogether).
I am now unable to open a support case with DJI via email.
</grumble>
This is just an example based on DJI, but there is a lot of misconfiguration like this on the web. Typically, those servers will ‘whitelist’ big providers like gmail, instead of fixing the problem.
It’s also interesting that gmail “only” sets up “~all” SPF policy — my policy is much stricter: “-all” — meaning that other servers should drop emails if they are impersonated. Badum tss. Web is awkward.
Open questions
At this point I wonder. Should DJI insert “Reply-To” header instead, and not touch the envelope? Would that pass DKIM? If not, how could they forward the email without dropping it? (frankly, my SMTP lingo is a bit rusty, I have not been a sysadmin for the last 10 years). Am I doing something wrong? I would assume that “it’s not my fault”.
Alternatively, they should do their SPF and DKIM validation on the 166.78.69.236 server, and then, any subsequent server of theirs should trust 166.78.69.236 — and not perform DKIM/SPF/DMARC validation on any email coming from 166.78.69.236.
Leave a Reply