ShadowTrackr
Log in >
This article will help you understand some common mailserver security problems. If you're in a hurry just go straight to the protocol you're looking for.
TLS Encryption as mentioned here and often in other explanations includes SSL. You should not use old SSL anymore and switch to the newer TLS versions, but if you do use SSL just assume it's included in the TLS definition for now.
Before we start, a short note about what the different "styles" of TLS are. Implicit TLS on a port means that whenever you connect to that port, it is expected that you always use TLS encryption. The opposite, explicit TLS, means that you only use TLS encryption if you explicitly say so to the server. If you don't mention anything, the connection will be unencrypted. Opportunistic TLS is the same as explicit TLS, and is also known by the command you send over the line to tell the server you are upgrading to a TLS connection: STARTTLS.
SMTP is used for sending mail between mailservers, and sending mail from your mailclient to a mailserver. Port 25 is intended for sending mail between mailservers, but some clients also use it to deliver email anyway. Port 587 was origianlly intended for clients to submit email to mailservers. Both ports have been in use since the old days when encryption wasn't common and STARTTLS was only added later (RFC 3207). Port 465 is the Implicit TLS variant of port 25, any connection to 465 is assumed to start with building up an encrypted TLS connection.
What should I do?
If ShadowTrackr shows an error on SMTP, your mailserver supports SMTP on port 25 or 587 but does not allow clients to initiate an opportunistic TLS connection. Your server does not understand the command STARTTLS. With this, you are forcing everyone to send their mail to you unencrypted, which is bad practice. You should update your server configuration to support STARTTLS. After that, the error will dissappear.
While you're at it, you could decide to receive only encrypted email. You can set most mailservers to require authentication (you don't want to be an open relay) and allow authentication only after TLS encryption is set up. This means non-TLS supporting systems cannot do email with you. Note that if you're in the business of receiving emergency messages by email, you might not want to do this.
If you decide you'll accept unencrypted email, but still want to force encryption on all your outgoing email, than have a look at REQUIRETLS.
POP3 is used to "pop" your email from a mailserver (after which it's no longer on the server and instead now lives on your client device), IMAP is used to "view" your mail on the server while your mail will remain on that server.Since the early, unencrypted days of internet POP3 is done on port 110, and IMAP on port 143. Later, implicit TLS was added on port 995 for POP3, and on port 993 for IMAP. That means port 110 and 143 are used for opportunistic TLS (STARTTLS).
What should I do?
If ShadowTrackr shows an error on POP3 or IMAP, your mailserver supports the protocol but does not allow clients to initiate an opportunistic TLS connection. Your server does not understand the command STARTTLS. This means that all clients that want to pop or view their mail on your server do so unencrypted. Besides the email, usernames and password are sent unencrypted too. Obviously, this is not good. You should enable STARTTLS on your server as soon as possible.
You can force most servers to require TLS form all clients too, and it will do so before accepting usernames and password. Good idea right? Unfortunately the mailclient might be unaware and still send the username and password unencrypted to the server. There is no support in POP3 or IMAP for the server to indicate it should not send unencrypted info, though some servers, like Dovecot will try to warn.
SPF is a method to allow you to specify which mailservers are allowed to send email for your domain. It's very useful to help prevent email spoofing like with phishing and SPAM. The SPF policy for a domain is set in a TXT record on your domain's DNS Server. Without an SPF record, the receiving mailserver has no way to know if the email was sent by a legitimate sender or not. SPF nicely complements DKIM, and you can even tell receiving mailservers what to do with both in a DMARC policy.
What should I do?
If ShadowTrackr shows an SPF warning for your domain, that means that you either have no SPF record set, or that your SPF record is set so wide that you allow everyone to send email on your behalf. If you don't send any mail from this domain, just set an SPF null record:
"v=spf1 -all"(remember to include the double quotes in your TXT record!)
If you do send email, specify the ip addresses or urls of the mailservers that are allowed to send email for your domain in the SPF record for that domain. There are plenty of tools to help you create a valid SPF record. Whichever one you use, make sure it ends with -all (meaning: only the ones listed) and not with ~all (meaning: the ones listed, and any other server on the internet too), +all (meaning: allow mail from any server), or ?all (meaning: no policy, just allow all).
<- back to FAQ