Frequently Asked Questions (FAQ)
Email Bounces / Email address requirements
We require that users provide a valid and properly configured email address for the purposes of being able to contact the user in case of problems. We thus expect users to provide an email account that they actually read on a regular basis. A personal/non-role account is prefered.
The current policy is codified and the validity of an e-mail address is determined as follows:
For the domain, the NS and MX records are looked up and resolved to their A and AAAA records so that we have a list of addresses. The MX records are then checked in the white- and blacklist again (such that we can accept e-mail domains hosted on well-known clusters. For each of the A (IPv4) addresses, we check a number of policy DNSBLs (such as zen.spamhaus.org, dul.dnsbl.sorbs.net, and dialups.mail-abuse.org) with the intent to find home-setups, which we do not accept.
Note:In a study performed by SixXS on 32019 e-mail addresses, we found that 11.2% of all addresses (3608) bounced at least once. Of the valid addresses, 9.49% bounced. Of the addresses that our new policy considers invalid, 16.6% bounced. We understand that our policy comes across as harsh, but we assert that it makes a difference to be strict.
In general: use your ISP's mail address, or a hosted solution, but don't run a mailserver at home - you may be listed in DNSBLs!
We expect that email accounts are reachable. If you are not reachable by email we cannot contact you regarding (mal)function of your tunnel. When we receive a bounce on an email address the account will automatically and directly be set into the disabled state. Connectivity provided to a disabled account will therefor be disabled.
If your e-mail address bounced, and you would like to have your connectivity back, update your handle with a valid email address in the appropriate registry and notify SixXS of the change, we can then reinstate your account.
Messages from your mailhost notifying us that the message we send could not be delivered (for example, greylisting longer than 5hrs) and other automatic replies are also treated as bounces and thus will automatically disable your account.
Common Email Configuration/Setup Mistakes
RFC1912 - Common DNS Operational and Configuration Errors lists a number of common problems, for instance MX DNS records pointing to CNAMEs¹. Domains that are misconfigured are not accepted.
Make sure that the domain of your email address is RFC compliant and has at least 2 distinctly separate working MX servers or a proven cluster solution. If your DNS contains only one MX record and it has a cluster behind it, direct signups will not be able to detect that, thus contact SixXS in that case. Mail servers on dynamically-assigned IP addresses and/or DSL/cable links are not accepted as they have proven not to be stable enough.
Check your domain using for example using ZoneCheck, DNSDoctor if it looks okay. If you have weird DNS records or had problems in your DNS setup, note well these could get cached in which case you won't be reachable either.
White- and Blacklists
In an attempt to be transparent on the e-mail verification system, here's the currently configured regular expressions for domains and MX hosts from which we automatically reject any e-mail address:Blacklist
As we do not want to encourage the usage of any provider we do not publish the whitelist. Of course, the white and blacklists are not final, if we notice that a domain is unacceptable even though it passes the above tests we may still consider rejecting the address.
If you have a properly set up ISP account, or another email account like one from work we prefer that you provide and use that. Setting up throwaway accounts will be noticed and such accounts will be rejected or disabled. To note, we specifically reject mailinator kind of accounts as these accounts are definitely not intended for proper email communication.
If you would like to file a petition to be added (or removed) from our white or blacklist, please contact SixXS and provide proper argumentation.
¹ = Using a CNAME in your domain breaks your email because sendmail (and possibly other SMTP software) will rewrite the domain portion of the destination email address to that of the label in the CNAME. See also CNAME records in mail by D. J. Bernstein. Note that having a CNAME for example.tld is of course impossible unless you get the tld to have the same record. Having an MX point to a CNAME record causes additional DNS lookups, which might cross a threshold, and thus cause your mail to be dropped. Additionally "Mail loops back to me" errors might be caused by this. Also see RFC1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES for more details. In short: Don't use CNAMEs in relation to SMTP.