From 4b73c622a4d5d0ef6d39efd77d5df1733cec81b1 Mon Sep 17 00:00:00 2001 From: Guilhem Moulin Date: Sun, 12 Jan 2014 21:51:42 +0100 Subject: typo --- tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn | 55 ---------------------- tracker/Publish_an_SPF_policy_to_the_DNS_zone.mdwn | 55 ++++++++++++++++++++++ ...ublish_the_DKIM_public_key_in_the_DNS_zone.mdwn | 17 ------- ...ublish_the_DKIM_public_key_to_the_DNS_zone.mdwn | 17 +++++++ 4 files changed, 72 insertions(+), 72 deletions(-) delete mode 100644 tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn create mode 100644 tracker/Publish_an_SPF_policy_to_the_DNS_zone.mdwn delete mode 100644 tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn create mode 100644 tracker/Publish_the_DKIM_public_key_to_the_DNS_zone.mdwn (limited to 'tracker') diff --git a/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn b/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn deleted file mode 100644 index a7bd78e..0000000 --- a/tracker/Publish_an_SPF_policy_in_the_DNS_zone.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -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_an_SPF_policy_to_the_DNS_zone.mdwn b/tracker/Publish_an_SPF_policy_to_the_DNS_zone.mdwn new file mode 100644 index 0000000..a7bd78e --- /dev/null +++ b/tracker/Publish_an_SPF_policy_to_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 deleted file mode 100644 index 7c564ae..0000000 --- a/tracker/Publish_the_DKIM_public_key_in_the_DNS_zone.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -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. diff --git a/tracker/Publish_the_DKIM_public_key_to_the_DNS_zone.mdwn b/tracker/Publish_the_DKIM_public_key_to_the_DNS_zone.mdwn new file mode 100644 index 0000000..7c564ae --- /dev/null +++ b/tracker/Publish_the_DKIM_public_key_to_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. -- cgit v1.2.3