On 4/28/2014 2:46 PM, Eric Shubert wrote:
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 *u...@a.com* & 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.
The match of the EHLO provided name and the PTR record (name) is
something that is becoming more and more important in SPAM fighting (see
FCrDNS on Google, or
http://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS) -- the issue
isn't so much as all out blocking, but SPAM labeling (or SPAM rejection
eventually).
NOTE: There does NOT have to be a relation or a match of the EHLO
provided host/domain name and the TO/FROM address -- the attempt to
validate with FCrDNS is an attempt to validate that the mail server
itself is legit. As-in, it is operating on static IPs that are
controlled by the same domain as they are advertising they are from....
it's not a strong check -- which is why there are seldom smtp rejects
due to a failure -- but let them mismatch and watch your SPAM labeled
mail jump at the likes of gmail and yahoo! (FWIW: its the domain names
that have to match, not so much the host names -- so having an EHLO
announce as mail.qmthosting.com and the PTR resolve to
generalserver.qmthosting.com won't matter -- so long as both
mail.qmthosting.com and generalserver.qmthosting.com both point to
1.2.3.4 -- the same IP address that we connected to).
- 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.
Point taken, but while you are correct, the TLS options add a complexity
that enjoys the exact same restrictions/problems as the SSL options. I
chose to leave it out because of that "duplicity", not because I was
unaware of it. FWIW - not all IMAP or POP servers support TLS, though I
am not aware of any that cannot support SSL on the assigned ports.
Also, the "stock" QMT (using courier imap) will crash if a client
attempts to connect on port 143 using TLS. The issue is one of available
memory in the run command's "softlimit" encasement. It was even worse in
the older method of making things work in 64-bit Linux, as the SSL
libraries were rather large.
In my own defense, I'll point out that my message was an attempt to show
"best practices" for hosting multiple domains, not a guide to all of the
options available to QMT configurations and interconnections.
- 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 will confirm that SSL and/or TLS are typically OPTIONAL on port 587...
However, I like to simplify things for my clients. If they want to use
their own domain name, then they use 587 with SMTP AUTH and no
encryption. After all, if they try to use TLS (or SSL) on ANY port with
their own domain name, they'll see the certificate mismatch errors we've
referred to earlier. (Handhelds and Thunderbird are the only clients I
know of that allow you to /EASILY /accept an "invalid" certificate --
others, like Outlook, make it much more difficult... after all, the cert
chain is definitely broken!)
Albeit, TLS connections (even SSL connections) *are* *actually
**available *on port 587, too... Sadly, most of my clients do not have
Computer Science degrees, nor NET+ certifications, so they get confused
/*easily*/... thus, for my client's "ease of understanding" sake: port
587 allows insecure authentication (e.g.: no certificate errors), and
port 465 requires secure connections, so you need to use _*MY
hostname*_, or deal with the certificate errors (/or buy your own
certificate/).
Thus, in my "best practices" opinion -- and while technically
incomplete, simple enough for clients to understand:
- 587 is left for unsecured SMTP AUTH, and 465 is used for REQUIRED
SSL/TLS connections.
Also: These are the 2 areas I differ significantly from the "stock" QMT
-- I enable port 465 (requiring SSL for client SMTP connections), and I
configure spamdyke to DENY SMTP AUTH on port 25.
I am concerned, however, when you say you plan to add spamdyke to port
587 (and presumably 465, optionally) in the future. In doing so, /if
you're going to maintain the rejection of SMTP AUTH on port 25/, you may
have to create a separate spamdyke config -- making things somewhat more
complicated.
Perhaps something to talk to the SpamDyke poeple about...
Also, while I take Symantec, Trend, & McAfee at their word -- that SMTP
AUTH on port 25 is a bad thing, I'd be interested to know why...
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!
Dan (again)
PS: for those who don't know Eric & me, we're both long (LONG!) time QMT
users and contributors. We typically agree on most technical issues in
the broader sense, we often have heated, detailed discussions (even
disagreements) over the intricate details. Speaking for myself, these
discussions have enriched my understanding of email, and Internet
technologies greatly, and I find great value in discussing (even
arguing) over technical details for that reason.
To my knowledge, there is no animosity at all (even in the slightest)
between Eric and myself -- even when we disagree vehemently! :)
ONE MORE ITEM -- Just to see if you're paying attention. There is
apparently a study underway where the USPS may offer a "secure e-mail
like service". It would not be free -- primarily as a way to cut down on
"bulk messaging" -- but it would be very-nearly-free to the normal user.
Ironically, while people routinely think e-mail has essentially the same
properties as snail-mail, the facts are that the privacy of e-mail comes
nowhere even close to the privacy of regular mail. (While you have no
real control over who might actually open your "letter", you can provide
a degree of certainty to the recipient that no one has looked at the
contents of a letter from the time it was "sealed" to the time it was
opened -- something you cannot say about email... a fact that disturbs
many email users when they learn just how many people COULD read their
messages... legitimately!)
IMHO, this might provide the opportunity we folks in the IT world have
been hoping for (at least seeking in a general way) -- that is, a way to
re-engineer EMAIL to be be "Internet Aware" (the original SMTP
specifications assumed "operators" would essentially know each other,
and thus, be able to police their users. The current Internet can in no
possible or conceivable way meet that expectation. so many of the
assumptions made in the original design of email are just plain wrong
(resulting in the MESS we have today). This might be a way to simplify
and "secure" email in a way that it could eventually actually replace
the current way of emailing.
Then again, they asked the USPS to look into this, so when the results
of the study come out in 2030, it will be based on the current
technology of 2008. :)
--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
