Eric Shubert wrote:
I'd like to know if this works, but I don't expect it will.
I believe that chkuser is not finding an MX record for the
backup.mydomain.com domain, and this cannot be specified in the hosts
file. An MX record for backup.mydomain.dom would need to be added to
the authoritative DNS for the mydomain.com domain. While this would
fix the problem, I don't think it's the best solution.
Fixing the problem at its source is preferable. (more on that elsewhere)
Adding an entry to DNS is the correct option. If a host does not have an
MX record, it should not be sending mail. If a host without an MX record
sends out mail, it's assumed that it's compromised and sending spam. I
also believe there is an RFC about this.
Here's a hypothetical scenario:
Bob has 2 servers. He sets one up as an email server and correctly adds
entries to DNS to support this (A record, MX record, PTR record, etc.).
Bob sets the second server up for web hosting, monitoring, whatever.
There is a MTA agent on the system (we'll say Exim), but he never
configured it and does not monitor it. He does however monitor his email
server's logs.
One day, the web server starts sending mail to everyone is can find. Bob
did not intend this server to send any mail, so he never configured DNS
for it to support this (no MX record, no PTR record). It's easy for us
to identify that messages from this server are not desired, since Bob
never configured it in DNS to send mail. How else is the rest of the
world supposed to know what hosts are allowed to send mail, and those
that are not?
Bob opens one of these messages (since he was emailed one, and he
configured his system to accept mail from invalid mail servers with no
MX records) and now has a virus. His home computer is now spewing out
thousands of spam messages a second to everyone in his address book.
Once again, it's easy for us to identify that messages from Bob's
infected home computer are safe to drop since he never set up DNS to let
us know it was intended to send emails (directly).
As email administrators, we have a responsibility to the rest of the
world to set things up correctly. We need to let the rest of the world
know that we want a specific machine to send mail by setting up the
proper structure for it (MX record, PTR record, etc.). Think of the
supporting entries in DNS as the license to send mail, just like you
need a license to drive a car. We trust our systems (legal, DNS,
otherwise) to correctly identify individuals (or machines) to do certain
things (drive, send email, whatever), otherwise we have anarchy and chaos.
I understand that there are exceptions to every rule, and Mike has a
valid exception to the above rules. The correct way for this to occur
would be to set his other system up to authenticate to one of his QMT
servers so it can send mail. Then he only has to manage one thing (DNS
for 1 server). I've posted about a program called "email" in a past post
about crons that would facilitate this.
Failing that, a couple simple config changes in Sendmail should fix this
as well - don't ask me what they are. I only work on Qmail and Postfix
and am assuming that it is easily configurable like Postfix or Qmail.
Just my 2-cents.
---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
