Fun with Tuffmail MX Restrictions
Par esteban le samedi 9 septembre 2006, 12:48 - Lien permanent
I've recently switched from my old email provider to Tuffmail. While their service looks really neat
so far, figuring out how to correctly set up your MX restrictions is, shall we
say, not entirely trivial. Since I scribbled down some notes trying to
make sense of them, I thought I might as well share them here in the oft-chance
that they may be of some use to other Tuffmail users.
Please note that I'm about as far as an email guru as you could imagine, so I'm not pretending to have any illuminating revelations about the nature of that beast to offer. Only, perhaps, to be able to light a candle in the dark.
A quick intro to SMTP
If you already know all about RFC 821 et al., you can skip directly to the next section.Email is transmitted across the internet through a protocol called SMTP, which stands for Simple Mail Transfer Protocol. And the reason they called it SMTP instead of just MTP is that, surprisingly, it really is simple. Actually, to be honest, the protocol now used is a new version called ESMTP (Extended SMTP) which, as you can surely astutely deduce, is slightly less simple. But we'll stick to SMTP because, for our needs, it contains all that we need to know.
A (very) simple SMTP transaction might look something like this:
>telnet mailserver.tld 25
220 mailserver.tld Welcome!
>HELO whoAmI
250 Hello whoAmI
>MAIL FROM:<sender@mydomain.tld>
250 Ok
>RCPT TO:<recipient@hisdomain.tld>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
>Subject: My first SMTP message!
>From: sender@mydomain.tld
>To: recipient@hisdomain.tld
>
>This is a test.
>.
250 Ok: queued as 12345
>QUIT
221 Bye!
Ok, what just happened there? Note: you can try this at home kids!
The first thing we did after connecting is issue the HELO command. This is used to say to the server which host just connected to it: "Hello, I am ...". Who you are is most likely your system or mailserver name, or your IP address or the name associated with it in a well-configured system.
The second command we sent was MAIL FROM. This, unsurprisingly, is telling the mailserver the identity of the person who is sending the message. We quickly followed that with the RCPT TO command, telling it who to deliver the message to.
Everything we typed after the DATA command is the actual email itself, which the mailserver does not really care about when delivering a message. Think of it like sending a good old-fashioned letter in the mail. You have an envelope and a letter inside it. The postman does not know and does not care about what you wrote in your letter, the only things he knows about it is what you wrote on the envelope. And to answer your question, yes, this means that the To: and From: headers inside your email bear no relation to whom the email is meant to, or to who actually wrote it. They are (mostly) just there to look good when your recipient reads it.
Tuffmail MX Restrictions
Note: This is not meant to replace the excellent information provided by Tuffmail, but simply to provide additional explanations and, when necessary, to correct erroneous entries that do not reflect the way the restriction actually works.One of the interesting things about discarding spam at this level is that the rejection occurs before the DATA command, meaning that the actual content of the email is never sent to the mailserver, saving bandwidth (and helping your monthly transfer limit) and cpu cycles by having less mail for the spam filters to go through. Our goal should therefore be to reject as much spam as possible without rejecting any legitimate emails, because emails discarded here are not recoverable, unlike those tagged as spam by the filters after being accepted by the server.
The only three things the mailserver cares about here are:
- the HELO command,
- the MAIL FROM:<> command,
- and the IP address of the sender (which is automatically known by simply connecting to the server and thus, which does not need to be sent as part the of SMTP transactions).
There are 4 categories of restrictions on Tuffmail:
- Global Restrictions are applied to every message passing through Tuffmail servers: (A), (B), (C) and (D).
- Local Restrictions are applied on a per-email address basis: (1) to (9)
- Greylisting Restrictions are applied on a per-email address basis but only reject mail temporarily, meaning that if the sender tries again after a delay of 5 minutes, his message will be accepted: (G1), (G2) and (G3)
- Blocklists Restrictions are applied on a per-email basis and are not covered here (but could be later if people show interest).
If we arrange them from least restrictive to most restrictive, it looks like this:
- HELO (A) -> (C) & (D) -> (9) -> (G1) -> (7) -> (3) -> (4)
- MAIL FROM (B) -> (1) -> (2) -> (8) -> (6)
- IP (G3) -> (5)
Each entry is constructed like this:
(#) Tuffmail description
Explanation>Telnet example
Rejection Report: the tag that appears in your daily Reject Report
Level: the default level at which this restriction is enabled if you don't customise your settings.
Global Restrictions
(A) The connecting SMTP client must issue a HELO or EHLO command.
>[trying to skip it]503 5.5.1 Error: send HELO/EHLO first
Rejection Report: None (rejected before being associated with your account)
(B) SMTP envelope addresses must be RFC-821 compliant
Valid MAIL FROM:<> and RCPT TO:<> commands must be sent.Note: Not 100% sure about this one. This is my best guess about what this restriction does.
>[trying to skip it]
503 5.5.1 Error: need [MAIL/RPCT] command
Rejection Report: None (rejected before being associated with your account)
(C) The host name in the HELO/EHLO command must not be the host name of Tuffmail MX servers.
Domain must not consist of:- mxin.mxes.net
>HELO mxin.mxes.net
504 5.7.1 <mxin.mxes.net>: Helo command rejected: Only spamware HELOs with my name
Rejection Report: Client rejected for HELO with this servers name or IP address
(D) The host name in the HELO/EHLO command must not be the IP address of the Tuffmail MX server.
Domain must not consist of:- 216.86.168.224
- 216.86.168.254
- 205.237.194.40
- 205.237.194.42
>HELO 216.86.168.224
504 5.7.1 <216.86.168.224>: Helo command rejected: Only spamware HELOs with my IP address
Rejection Report: Client rejected for HELO with this servers name or IP address
(E) The host name in the HELO/EHLO command must not contain any of the following invalid characters: ? @ # $ % ^ & * ( ) + = \ / ~ ` " < > : ; , ' _
Note: Not really global, inactive unless you enable (9).>HELO @foo
504 5.7.1 <@foo>: Helo command rejected: Illegal character in HELO; See RFCs 821, 2821, 1123
Rejection Report: Illegal character in HELO; See RFCs 821, 2821, 1123
(F) The name given in the HELO/EHLO command must not be in this list of frequently forged names: aol.com, compuserve.com, earthling.net, earthlink.net, netzero.com, yahoo.com.
Note: Not really global, inactive unless you enable (9).>HELO aol.com
504 5.7.1 <aol.com>: Helo command rejected: You are not an MTA for the aol.com domain
Rejection Report: Client HELO rejected for pretending to be 'forgeddomain.tld'
Local Restrictions
(1) Require Fully Qualified Sender
The envelope sender address must be in the following formats:- user@domain.tld
- user@something.domain.tld
- etc.
Note: The TLD doesn't have to be valid and neither does the domain itself necessarily have to really exist.
>MAIL FROM: <foo>
504 5.5.2 <foo>: Sender address rejected: need fully-qualified address
Rejection Report: need fully-qualified address
Level: Ultra conservative
(2) Require Valid Sender Domain
The domain in the envelope sender address must resolve to an IP address or to an MX server that resolves to an IP address.Note: Only the domain has to resolve. This does not ensure that the email address entered actually exists.
>MAIL FROM: <foo@nonexistantdomain.net>
550 5.1.8 <foo@nonexistantdomain.com>: Sender address rejected: Domain not found
Rejection Report: Sender domain not found
Level: Ultra conservative
(3) Require Valid Hostname in HELO/EHLO Command
Domain must only consist of:- alphanumeric characters (a-z, 1-0)
- minus signs (-)
- periods (.)
>HELO foo!
501 5.5.2 <foo!>: Helo command rejected: Invalid name
Rejection Report: Invalid client HELO
Level: Aggressive
(4) Require FQDN (Fully Qualified Domain Name) in HELO/EHLO Command
Domain must be in the following formats:- domain.tld
- something.domain.tld
- etc.
Note 1: The TLD must be valid (ex: .com and .net, but not .foo), but the domain itself doesn't necessarily have to really exist (ex: nonexistantdomain.net will pass).
Note 2: .local and .corp are considered valid TLDs for this restriction.
>HELO foo
550 5.7.1 <foo>: Helo command rejected: foo is not a valid host name
>HELO domain.foo
550 5.7.1 <domain.foo>: Helo command rejected: foo is not a valid TLD
Rejection Report: Invalid client HELO
Level: Aggressive
(5) Require Reverse DNS
A reverse DNS query must translates the IP address of the sender to a name.Note: Due to the lack of a non-DNS enabled IP, I was not able to test this restriction.
Level: Very Aggressive
(6) Reject mail with Forged Sender Addresses
If the message is received from a server that is not in the following domains, the envelope sender address must not be from those domains:- yahoo.com, hotmail.com, lycos.com, excite.com
- any of the 275 Outblaze domains (email.com, mail.com, artlover.com, dr.com, usa.com, munich.com, minister.com, europe.com, etc.)
>MAIL FROM: <foo@hotmail.com>
554 5.7.1 <foo@hotmail.com>: Sender address rejected: Please use a mail server for hotmail.com
Rejection Report: Forged Sender Restriction for domain.tld
Level: Aggressive
(7) Forged Hostname in HELO/EHLO Command
Rejects mail from clients that issue a HELO or EHLO command with a host name that is in a domain name that this system handles email for.Note 1: This doesn't include all the domains managed by Tuffmail, only the ones that you add to your account.
Note 2: For this restriction to work, you must also check "Reject mail from SMTP clients that forge this domain in their HELO/EHLO command" under Domain > Options for all the domains you wish to protect (it is off by default, contrary to what the FAQ mentions).
>HELO yourdomain.tld
504 5.7.1 <yourdomain.tld>: Helo command rejected: Client HELO rejected for pretending to be yourdomain.tld
Rejection Report: Client HELO rejected for pretending to be 'yourdomain.tld'
Level: Conservative
(8) Enable Sender Policy Framework (SPF) Checks
If the envelope sender address is from a SPF protected domain, the message must have come from a mail server authorised to send mail for this domain.Note: Softfails (~) will be accepted (but will be tagged by the spam filters), not rejected.
>MAIL FROM: <foo@spfprotected.tld>
554 5.7.1 <foo@spfprotected.tld>: Recipient address rejected: Please see http://www.openspf.org/why.html?sender=[sender]&ip=[ip]&receiver=[receiver]
Rejection Report: Please see http://www.openspf.org/why.html?sender=[sender]&ip=[ip]&receiver=[receiver]
Level: Aggressive
(9) Reject mail with Obvious spamware HELO/EHLO
Domain must not be any of the following:- a decimal or hexadecimal number
- an IP address
- the following strings: baby, billgates, default, ebox-bulk-email-software.com, friend, mycomputer, oemcomputer, speedtouch.lan
- any strings beginning with: oem-micro, windowsxp, -
Note: Also enable (wrongly-named) Global Restrictions (E) & (F)
>HELO billgates
504 5.7.1 <billgates>: Helo command rejected: Obvious spamware HELO from a compromised Windows machine; See RFCs 821, 2821, 1123
Rejection Report: Obvious spamware HELO from a compromised Windows machine; See RFCs 821, 2821, 1123
Level: Ultra conservative
Greylisting Restrictions
Instead of being issued a permanent failure code (5xx), mail from a sender (defined by: sender IP, envelope sender address and envelope recipient address) rejected due to greylisting will be issued a temporary failure code (4xx) and will be accepted if resent more than 5 minutes later. Once accepted, mail from the same IP will not be greylisted for 30 days.
(G1) Greylist bogus HELO/EHLO command
The host name in the HELO/EHLO command must contain a dot [.]Note 1: This doesn't prevent totally bogus domains like @_@. or .foooooooooo! As long as there is a dot somewhere, anything will be accepted.
Note 2: The only exception is that any 3 or more numbers separated by a dot[.] or a dash [-] followed by a dot followed by anything will be rejected. For exemple: foo.1.2.3.4.foo and 11-22-33.foo will be rejected.
>HELO bogusdomain
450 4.7.1 <bogusdomain>: Helo command rejected: Greylisted, please try again
Rejection Report: Client HELO Greylisted
Level: Very Conservative
(G2) Greylist suspect senders
This does not do anything (does not work).Level: Never enabled
(G3) Suspect IP address
Sender IP:- must not be a dynamic IP
- must, with a reverse DNS query, translates to a name
- must not, with a reverse DNS query, translates to a name that looks like a dynamic IP.
Note: Due to the IPs I have access to, I could not test this fully.
>[...]
450 4.7.1 <ip192-168-1-1.domain.tld[192.168.1.1]>: Client host rejected: Greylisted, please try again
Rejection Report: Client name or IP address greylisted
Level: Very Conservative
Final thoughts
In case anyone is wondering, my own settings are: 1-4789G3BaBd. Meaning everything but 5 (too many misconfigured Exchange Servers around), 6 (having not seen the need for it yet, but this may change), G1 (useless) and G2 (obviously). I also use the two Spamhaus databases: Ba & Bd. With this I have been able to cut my spam by more than 98% (and that is before the spam filters quick in!) without rejecting a single legitimate email yet. Obviously, depending on your own circumstances, your needs may well vary from mine.While it will not protect you from spam, it does protect others, so you should really enable SPF (Sender Policy Framework) on your domain. Please see the Tuffmail recommended settings and the OpenSPF website.
And that's it! Hopefully you have found this little guide helpful. If you have any questions, please check out this thread on the Tuffmail forum.