Merge branch 'master' into terminal
This commit is contained in:
commit
20b77e01e8
GPG key ID:
3F257B68F5BC9339
1 changed files with 156 additions and 1 deletions
|
|
@ -1059,7 +1059,137 @@ non_smtpd_milters = $smtpd_milters
|
||||||
This uses the Milter extension, which is something that can be used to process mail; in this case, to add headers to
|
This uses the Milter extension, which is something that can be used to process mail; in this case, to add headers to
|
||||||
emails relating to DKIM.
|
emails relating to DKIM.
|
||||||
|
|
||||||
<!-- TODO DMARC section here -->
|
## Domain-based Message Authentication, Reporting, and Conformance
|
||||||
|
|
||||||
|
### Ensure your domains are aligned in email headers
|
||||||
|
|
||||||
|
Send a test email from your domain and look at the email headers of the sent email.
|
||||||
|
|
||||||
|
``` {hl_lines=[1,11,23]}
|
||||||
|
Return-Path: <pid1@revsuine.xyz>
|
||||||
|
Received: from master.revsuine.xyz (master.revsuine.xyz. [93.113.25.226])
|
||||||
|
by mx.google.com with ESMTPS id ffacd0b85a97d-3825fb5a132si1538595f8f.66.2024.11.22.08.53.01
|
||||||
|
for <revsuine@gmail.com>
|
||||||
|
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
|
||||||
|
Fri, 22 Nov 2024 08:53:01 -0800 (PST)
|
||||||
|
Received-SPF: pass (google.com: domain of pid1@revsuine.xyz designates 93.113.25.226 as permitted sender) client-ip=93.113.25.226;
|
||||||
|
Authentication-Results: mx.google.com;
|
||||||
|
dkim=pass header.i=@revsuine.xyz header.s=default header.b=HRewRpbu;
|
||||||
|
spf=pass (google.com: domain of pid1@revsuine.xyz designates 93.113.25.226 as permitted sender) smtp.mailfrom=pid1@revsuine.xyz;
|
||||||
|
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=revsuine.xyz;
|
||||||
|
s=default; t=1732294380;
|
||||||
|
bh=Q6d5/50T+3BnL4k+i/ARiher4CIHkBrfcsHufAU/i4E=;
|
||||||
|
h=Subject:From:To:Date;
|
||||||
|
b=HRewRpbuXhaI4vf8ZXc0PzepcNAd5mGDvWh38mAF+JYvefM7pF+q0dNYrA0bCrCys
|
||||||
|
a6qev9C++7hJC7oLYKgcXoewHPiGQzfgjj5oIVuIE10CSuSNyk4vd4Nf37P8k1A8lO
|
||||||
|
jy+g+kv7VbX5N+ElzQbqXL1PTjgd9seDYoPn5FTTWGfVbLhh6gWfU3xeb88UZQCFJ+
|
||||||
|
kgWMFOUEjoTffzqNBe/NICvcoX3ZJvr+vCdZVANHEV1AhVExDB9FM/0TRFnybhTVo0
|
||||||
|
eGDCEtvkxgNQYVFVnJUxWZ3MCt+cDVuYVsHw0SXQMToiNSPlsn65iV2+/giw7DmSCo
|
||||||
|
fgOvYG+eHu10w==
|
||||||
|
Message-ID: <47971a581909651b6e089287b5b408fd56352b82.camel@revsuine.xyz>
|
||||||
|
Subject: Test
|
||||||
|
From: revsuine <pid1@revsuine.xyz>
|
||||||
|
```
|
||||||
|
|
||||||
|
Ensure that the domains in `Return-Path`, `DKIM-Signature`, and `From:` are the same. If they are, they are strictly
|
||||||
|
aligned. Or if the `Return-Path` or `DKIM-Signature`'s `d=` parameter use a subdomain instead of the main domain name
|
||||||
|
in the `From:` field, they have relaxed alignment. Either way, they are aligned.
|
||||||
|
|
||||||
|
By default, DMARC uses relaxed alignment. Your domains have to be aligned in order to pass DMARC checks.
|
||||||
|
|
||||||
|
### Create a DMARC DNS record
|
||||||
|
|
||||||
|
Create a TXT record with `_dmarc` as the record name, and
|
||||||
|
|
||||||
|
```
|
||||||
|
v=DMARC1; p=none; pct=100; fo=1; rua=mailto:dmarc@domain.com
|
||||||
|
```
|
||||||
|
|
||||||
|
as the TXT data, replacing `dmarc@domain.com` with an email address you want mail servers to send their DMARC reports
|
||||||
|
to.
|
||||||
|
|
||||||
|
#### Policies
|
||||||
|
|
||||||
|
`p=none` indicates the policy for our DMARC record. The available policies are:
|
||||||
|
|
||||||
|
<!-- yk the drill, html table for line breaks -->
|
||||||
|
|
||||||
|
<table>
|
||||||
|
<tr>
|
||||||
|
<th>Policy</th>
|
||||||
|
<th>Meaning</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>none</code></td>
|
||||||
|
<td>Don't do anything if the DMARC check fails</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>quarantine</code></td>
|
||||||
|
<td>
|
||||||
|
Quarantine emails if DMARC check fails; an admin must approve the email before it reaches the recipient's
|
||||||
|
inbox
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>reject</code></td>
|
||||||
|
<td>Reject the email if DMARC check fails</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
|
It's recommended to start with `none` or `quarantine` until you're sure that your emails are passing DMARC. `none` is
|
||||||
|
more appropriate for domains that have already sent some emails; if you've never sent email from your domain before,
|
||||||
|
try `quarantine` with `pct=30` (see below) as a start.
|
||||||
|
|
||||||
|
If your domain is not going to send emails, set `p=reject`.
|
||||||
|
|
||||||
|
#### Percentage
|
||||||
|
|
||||||
|
`pct=100` means that a mail server should expect 100% of incoming mail from your domain to pass DMARC checks. As you
|
||||||
|
increase the strictness of your policy, you should also decrease `pct` until you are sure that your email is passing
|
||||||
|
checks.
|
||||||
|
|
||||||
|
[LinuxBabe](https://www.linuxbabe.com/mail-server/create-dmarc-record) recommends the following "progression", moving
|
||||||
|
to the next row in the table as you've tested the previous row and haven't seen legitimate mail rejected:
|
||||||
|
|
||||||
|
| Policy | Percentage |
|
||||||
|
| ------------ | ---------- |
|
||||||
|
| `none` | 100 |
|
||||||
|
| `quarantine` | 30 |
|
||||||
|
| `quarantine` | 70 |
|
||||||
|
| `quarantine` | 100 |
|
||||||
|
| `reject` | 30 |
|
||||||
|
| `reject` | 70 |
|
||||||
|
| `reject` | 100 |
|
||||||
|
|
||||||
|
#### Email reports
|
||||||
|
|
||||||
|
You set an email address for DMARC reports to be sent to with `rua=mailto:dmarc@domain.com`. This means that when a
|
||||||
|
mail server receives email from your domain, if it runs a DMARC check, it will send the results to that email.
|
||||||
|
|
||||||
|
The `fo` tag indicates when you would like to receive reports. The options are:
|
||||||
|
|
||||||
|
<table>
|
||||||
|
<tr>
|
||||||
|
<th>Option</th>
|
||||||
|
<th>Meaning</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>0</code></td>
|
||||||
|
<td>Generate reports if <strong>all</strong> authentication mechanisms fail</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>1</code></td>
|
||||||
|
<td>Generate reports if <strong>any</strong> authentication mechanisms fail</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>d</code></td>
|
||||||
|
<td>Generate reports if DKIM authentication fails</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td><code>s</code></td>
|
||||||
|
<td>Generate reports if SPF authentication fails</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
### Test SPF, DKIM, and DMARC
|
### Test SPF, DKIM, and DMARC
|
||||||
|
|
||||||
|
|
@ -1068,6 +1198,31 @@ and DMARC are all working for your server.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Failure
|
||||||
|
|
||||||
|
There are a few things that can cause SPF, DKIM, and consequently DMARC to fail.
|
||||||
|
|
||||||
|
One common scenario is email relaying causing SPF to fail, because the recipient mail server does not receive the email
|
||||||
|
directly from your mail server.
|
||||||
|
|
||||||
|
#### Mailing Lists
|
||||||
|
|
||||||
|
"Announcement" type mailing lists can cause DKIM failure, because usually additional headers are added to your emails.
|
||||||
|
"Discussion" type mailing lists are more problematic; they can also cause SPF failures because emails are coming from
|
||||||
|
all different mail servers through the mailing list server, and the central mailing list server cannot sign other
|
||||||
|
domain's DKIM signatures.
|
||||||
|
|
||||||
|
For announcements, if you are using an external mailing list provider, just add their server to your SPF record. For
|
||||||
|
discussion mailing lists, resolving authentication issues is more complex. [GNU Mailman has a wiki article with some
|
||||||
|
suggestions.](https://wiki.list.org/DEV/DMARC)
|
||||||
|
|
||||||
|
# Amavis
|
||||||
|
|
||||||
|
# Miscellaneous suggestions
|
||||||
|
|
||||||
|
You may want to get your domain whitelisted on [dnswl.org](https://www.dnswl.org/), an email whitelist service where
|
||||||
|
admins can submit their domain and IP address to indicate trustworthiness.
|
||||||
|
|
||||||
<!-- FOOTNOTES: -->
|
<!-- FOOTNOTES: -->
|
||||||
|
|
||||||
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
|
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue