Nice write-up, Dan. I'd like to make a few additional points, inline.
On 04/28/2014 10:55 AM, Dan McAllister wrote:
Kelly:
While Eric's reply is clear about the fact that the MX record has to use
an A record reference (vs CNAME), I think the answer you need here is
simply that the A-record has to point to the correct IP address. What
name you put in the MX record is of little import, so long as it
references an A record that points to the correct IP address.
===
By way of examples (for other users):
Say my mail host is at 10.0.0.2, behind a NAT router with WAN IP address
*1.2.3.4* (apologies to Google for using their IP in my example).
- my mail host listens on ALL the standard ports (25, 80, 110, 143,
443, 465, 587, 993, & 995) for web and mail hosting (all forwarded
through my router).
- my mail host uses a name of *mail.qmthosting.com* (that's one of MY
OWN hosting domains, so no worries about using it here)
- my clients each have their own domains (for grins, we'll use
*a.com*, *b.com*, *c.com*, etc)
- in general, my clients DNS servers (whether hosted by me or not,
with entries for their domains that look like:
* @ IN MX 10 mail**
** mail IN A 1.2.3.4*
Thus, to the outside world, they have an MX server at *mail.a.com*,
which resolves to *1.2.3.4*. (Their domain name, their A record, my IP
address).
Now, where the SPAM detection for IP addressing starts is when an
outside mail server connects:
- sendingdomain.com wants to send to *[email protected]* & detects the MX
record is *mail.a.com*, which resolves (by A-record) to *1.2.3.4*
- sendingdomain.com connects to *1.2.3.4* on port 25 and gets an *EHLO
*response that the name of the server is *mail.qmthosting.com*
- sendingdomain.com then does a DNS query for *mail.qmthosting.com*
and gets an IP of *1.2.3.4* -- so far, so good
- sendingdomain.com next does a DNS query for 1.2.3.4 (actually,
*4.3.2.1.in-addr.arpa*) and gets a PTR value of *mail.qmthosting.com* --
bingo! a match!
This is equivalent to the reject-missing-rdns spamdyke rule. However,
whether these names match or not is irrelevant. Matching *might* affect
treatment of spam, but not matching must not effect whether mail is
accepted or not. Matching is certainly better, but I've yet to see an
example of it being required.
In addition, the name given in the rDNS/PTR record *must* resolve to
*some* IP address in order to be deliverable to many servers. This is
equivalent to the reject-unresolvable-rdns spamdyke rule. Again, the IP
address doesn't need to match anything. The name simply needs to be
resolvable.
- sendingdomain.com continues sending the message (presumably to a
domain in the rcpthosts file)...
The trouble comes when you want to connect your */clients/*...
- for *webmail*, I simply create an entry for each domain
(*https://mail.a.com*, etc) that redirects to the real ssl page
*https://mail.qmthosting.com*. That way the SSL certificate (which only
has the name mail.qmthosting.com in it) works. (I do not allow webmail
access except through https).
- for IMAP mail, there are 3 options:
a) connect to *mail.a.com* on port *143 *and use *IMAP *with /_no
security_/ (BAD IDEA -- I only allow this on one host, and only because
the client INSISTS upon it)
b) connect to *mail.a.com* on port *993 *and use *IMAP over SSL* --
clients will have /varying degrees of difficulty /as the SSL Cert won't
match the host name
c) connect to *mail.qmthosting.com* on port *993 *and use *IMAP
over SSL* with my_*trusted SSL certificate*_ (names match, so no errors,
and no worries!)
NOTE: Most clients choose option C -- in large part because I tell
them to :)
I hate to point this out, but there are other options. ;)
TLS (aka StartTLS) is an alternative (and arguably preferred) option to
SSL. TLS on port 143 is essentially the same as SSL on port 993. The
encryption is the same, but the implementation/protocol is slightly
different. SSL requires the entire session to be encrypted, while TLS
allows an unencrypted session to dynamically switch to encrypted.
The same issues with certs applies to TLS as to SSL, as that part is the
same. I agree that option C is the simplest. Most clients these days
seem to have a simply way to accept the B certificate permanently, so
this isn't as big of a deal as it used to be. Still a little annoying
though.
- The same general idea goes for POP access, only on ports 110 and 995.
SMTP access is a little more tricky... it is a BEST PRACTICE to disallow
SMTP-AUTH on port 25 (because it can be abused -- I'm not sure how, but
all the major anti-virus and anti-spam companies tell me so, and I'm not
of a need to determine exactly why -- I have bigger fish to fry!). Since
this is the only un-authenticated access to the system, this port's SMTP
service is plugged into SPAMDYKE -- which has been told to NOT allow
SMTP-AUTH. But that is OK, because we're talking about CLIENT access to
an SMTP server here:
- I allow SMTP-AUTH with or without SSL on port 587 (if you choose to
enable SSL, remember that the certificate is for the site
mail.qmthosting.com)
- I allow SMTP-AUTH only with SSL on port 465 (again, remember that
the certificate is for the hostname mail.qmthosting.com).
So, clients can configure their SMTP access as being on port 587 using
mail.a.com, or port 465 using SSL and the host name mail.qmthosting.com.
Note, TLS is highly recommended for port 587 access.
Note, the stock QMT doesn't support port 465 yet. Also, the stock
spamdyke configuration does allow authentication on port 25.
The stock QMT will be changing at some point to be in line with Dan's
configuration. We'll also be adding spamdyke to the submission (port
587) configuration to handle authentication. I hope to do all that in a
single release.
I really need to post some of this on the WIKI ... sigh when I'm less
overworked :)
Let's get it on github, so we don't have one more thing to convert. ;)
Thanks Dan!
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
