summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--tracker/Publish_all_certificates_reachable_from_outside_to_the_monkeysphere.mdwn4
-rw-r--r--tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn55
-rw-r--r--tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn17
3 files changed, 76 insertions, 0 deletions
diff --git a/tracker/Publish_all_certificates_reachable_from_outside_to_the_monkeysphere.mdwn b/tracker/Publish_all_certificates_reachable_from_outside_to_the_monkeysphere.mdwn
new file mode 100644
index 0000000..cbdfb3d
--- /dev/null
+++ b/tracker/Publish_all_certificates_reachable_from_outside_to_the_monkeysphere.mdwn
@@ -0,0 +1,4 @@
+The admins should also sign the generated OpenPGP key, so that
+non-admins members can rely on the Web of Trust instead of the usual CA
+model. (Both are compatible, by the way.) See
+[[http://web.monkeysphere.info/]].
diff --git a/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn b/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn
new file mode 100644
index 0000000..a7bd78e
--- /dev/null
+++ b/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn
@@ -0,0 +1,55 @@
+We need to create a new subdomain `outgoing.fripost.org` which A and
+AAAA records point to machines currently serving as outgoing SMTP
+servers. Then we would add the following records to the DNS zone
+([RFC 4408 section 3.1.1](https://tools.ietf.org/html/rfc4408#section-3.1.1)
+recommends both SPF and TXT records, with identical content.):
+
+ outgoing.fripost.org IN SPF "v=spf1 a ~all"
+ outgoing.fripost.org IN TXT "v=spf1 a ~all"
+ fripost.org IN SPF "v=spf1 redirect=outgoing.fripost.org"
+ fripost.org IN TXT "v=spf1 redirect=outgoing.fripost.org"
+
+That essentially means whenever someone receives a message from a
+`@fripost.org` address, we can say the address hasn't been spoofed (or
+been spoofed by another fripost member) if the message was originating
+from `outgoing.fripost.org` (i.e., was sent from the webmail, the Mail
+Submission Agent, or was the target of an alias or subscribed on a
+list). Otherwise, things are like there wasn't an SPF policy. With that
+information at hand, the recipient may decide to classify the message as
+SPAM or HAM for instance.
+
+If we were to disallow (we probably aren't) messages from `@fripost.org`
+addresses to be sent from anything else than what `outgoing.fripost.org`
+points to, we could replace the trailing `~all` (softfail) by `-all`
+(fail).
+
+Having an SPF policy for Fripost is also useful for domains using
+fripost.org as MX:es. For instance, to allow `@example.org` messages to
+be sent from either `fripost.org`'s outgoing machines (without knowing
+what they are a priori, therefore the SPF policy is copied) or
+`example.org`'s A/AAAA records, but nothing else:
+
+ example.org IN SPF "v=spf1 ?include:fripost.org a -all"
+ example.org IN TXT "v=spf1 ?include:fripost.org a -all"
+
+Hopefully one day we'll have DNSSEC, defeating DNS-spoofing. The the
+[qualifier](https://tools.ietf.org/html/rfc4408#section-5.2) could be
+changed to something tighter:
+
+ example.org IN SPF "v=spf1 include:fripost.org a -all"
+ example.org IN TXT "v=spf1 include:fripost.org a -all"
+
+Here too the default action `-all` (fail) could be replaced by `~all`
+(softfail) to allow mails from `@example.org` addresses to be sent from
+other locations, but without asserting they aren't spoofed in that case.
+
+If `example.org`'s has no A/AAAA records, or if the machine they point
+to are not supposed to relay mails to the outside, one may prefer to
+merely copy our policy:
+
+ example.org IN SPF "v=spf1 redirect=outgoing.fripost.org"
+ example.org IN TXT "v=spf1 redirect=outgoing.fripost.org"
+
+References: RFCs [4408](https://tools.ietf.org/html/rfc4408) and
+[6652](https://tools.ietf.org/html/rfc6652); See also the
+[Wikipedia page](https://en.wikipedia.org/wiki/Sender_Policy_Framework).
diff --git a/tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn b/tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn
new file mode 100644
index 0000000..7c564ae
--- /dev/null
+++ b/tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn
@@ -0,0 +1,17 @@
+So anyone receiving an e-mail from `fripost.org`'s outgoing SMTP server
+(possibly indirectly) can decide whether it's legit or tampered with.
+
+The DKIM public key should be added to `fripost.org`'s DNS zone as a TXT
+record, as follows:
+
+ 20140112._domainkey.fripost.org. 86400 IN TXT "v=DKIM1\; k=rsa\; p=…"
+
+Having one sub-domain (here `20140112`, the date where the key was
+generated) is what Google does; that's a clever way to allow multiple
+keys, which is useful for a smooth transition to a stronger key for
+instance.
+
+See RFCs [6376](https://tools.ietf.org/html/rfc6376) and
+[7001](https://tools.ietf.org/html/rfc7001) for references. The
+[Wikipedia page](https://en.wikipedia.org/wiki/Dkim) might be another
+good read.