No Relation To Blog
Subscribe to the personal musing of Emmanuel Bernard
Recently running rsync to my Synology diskstation stopped working. I had just changed my default SSH port to a non standard one. Learn how to fix it.
Synology recommends to change the default SSH port to a non standard one. What they forgot to tell you is that it will break your ability to rsync into the machine. Here is a way to fix it.
The workaround way
One way to fix it is to use the
rsync -avz --rsync-path=/usr/syno/bin/rsync from-dir/ synology:/volume1/Backups/to-dir
Since you use a non standard SSH port, make sure to also update your
.ssh/config file to point to the right one.
Host synology User alice Hostname 192.168.2.34 # my synology IP Port 911 # my new SSH port and a nice car
That works around the Synology quirk but it requires to update all your rsync scripts.
The proper way
Log to the web management console and open the
Backup & Replication application.
Backup Services and update the
SSH encryption port to match your new SSH port,
in my example
Note that for some reason the UI forbids certain port numbers.
Make sure to use a non restricted number for your SSH port in the first place or use trial and error.
The SSH port can be changed in the
Terminal & SNMP.
I have decided to move this website to HTTPS. Let me know if you see anything fishy, cannot access it or if the RSS feed no longer updates. Why? With my country's government going completely stupid, I decided to play the nut game, I can be pretty stupid too.
In its infinite wisdom, the French government has decided to enable mass surveillance of the French people without oversight of the justice branch. Yes I know WTF?!
Anyways, in order to make things simpler for them, I have decided to move all of my web properties behind HTTPS (HTTP over TLS). Do I have anything to hide? Nope, I just want to increase universe entropy and cracking our communication a bit more challenging.
My certificate fingerprints are:
- SHA1: 15 3E 2E 67 39 28 20 28 6E F6 CF F5 E1 92 AB 07 72 32 72 90
- MD5: 0B 2D 49 61 DE EA E1 D7 11 92 BA 3D 4F BD 73 E2
If you see something else then, you are being intercepted. Read more on secure connection fingerprints.
In this post, you will learn everything you need about SPF (Sender Policy Framework), what it means for your emails and how / if to set it up for your domains.
What is it for and should I care?
This is a standard that helps reduce spam. Each domain lists in one DNS record the list of servers that are allowed to send emails for that domain. So when an email provider like Gmail sees an email sent from an address @example.com but coming from a server not listed in the SPF record, it knows it is likely a spam.
Conversely, it is important to set such a record to avoid your emails to be considered spam. More and more email providers consider domains without SPF record as more suspicious than others. Even if you domain does not send emails, you should set a SPF record, this will prevent spammers from faking emails from you.
How does it work ?
As owner of a given domain, you will tell the world which servers you will send emails from. That is typically your SMTP server.
In practice, this is a TXT entry in the DNS records of your domain. Something like
"v=spf1 a include:_spf.google.com ip4:198.51.100.3 -all"
v=spf1 is the protocol, all entries start with this.
a or generally
a:example.com says that all IPs listed in the DNS A record of the domain should be able to send emails for that domain.
If the domain is not specified (
a), then it is the domain for which the TXT DNS record lives.
ip4:198.51.100.3 means that IP 198.51.100.3 is allowed to send emails for your domain.
You can assign ranges as well.
Likewise, there is an
include:_spf.google.com means that you should consider the SPF rules stored in the DNS entries of
This is very useful if you use Google Apps / Gmail or send emails from another domain's SMTP server.
Rules can be composed, so you can have explicit ips, a and includes in the same SPF entry.
There are also
ptr entries but I won't go into details.
Finally, you need to decide what to do when the rules don't match.
That's where the
all mechanism comes into play:
-allmeans that servers that do not pass the rules should be considered spammers
~allmeans that servers that do not pass the rules should be considered spammers but we are not 100% sure so let them pass but be suspicious
?allmeans that servers that do not pass the rules should be considered neutral (i.e. they may be legit or not)
If your list is exhaustive, use
-all to lock things down.
If people sending emails from your domain might use their own SMTP server, use
~all is for chickens ;)
You can get a formal description of all the options at openspf.org.
You can lookup the SPF entries for any domain by typing
nslookup -q=TXT example.com
This is useful before you add an
A few concrete examples
My domain never sends any email:
I use Gmail / Google Apps to send emails from that domain:
"v=spf1 include:_spf.google.com -all".
I use Gmail and Red Hat's SMTP:
"v=spf1 include:_spf.google.com include:redhat.com -all".
I use the server hosting example.com and Red Hat's SMTP:
"v=spf1 a include:redhat.com -all" (this is a short hand for
"v=spf1 a:example.com include:redhat.com -all"
People sending email as other-example.com use various SMTP servers but for sure 198.51.100.3 and it's corresponding IPv6 2001:db8::df4:cd23 and example.com's SMTP servers:
"v=spf1 ip4:198.51.100.3 ip6:2001:db8::df4:cd23 include:example.com ?all"
A note on TXT DNS entry, to use (I think) the bind syntax, here is how it looks like
# let's say it's the DNS zone of example.com # some domain @ 10800 IN A 198.51.100.3 # some subdomains awesome 10800 IN CNAME example.com. blog 10800 IN CNAME example.com. # looks like these guys use Google Mail @ 10800 IN MX 10 aspmx.l.google.com. awesome 10800 IN MX 10 aspmx.l.google.com. # Here is our subject # you need one entry per domain and subdomain sending emails @ 10800 IN TXT "v=spf1 a include:_spf.google.com -all" awesome 10800 IN TXT "v=spf1 a include:_spf.google.com -all" # blog never sends emails blog 10800 IN TXT "v=spf1 -all"
Conclusion and a few recommendations
I prefer domain names over IPs so I use
As much as I can, I use
include and delegate the list to the real guys.
Google and others use special subdomains like
_spf.google.com to host their SPF rules.
This is useful to separate different ruleset but bind them together in your primary domain via an
If you are one of them, you probably don't need my blog entry in the first place :)
Remember that servers now have IPv6 addresses and that Google and other have already IPv6 infrastructures in place. Don't forget them, I had some emails denied because I was missing it and my server communicated with Google from an IPv6.
My take out is simple: if you own a domain and send emails, add a SPF entry. It's relatively simple and the examples I gave you should get you a long way already.
PS: I am relatively new to this domain, feel free to correct me in the comments, if I made a mistake.