Eric Shubert wrote:
While I agree with your position and hypothetical scenario, I don't
believe that adding an MX record for each host is the correct nor best
solution.
I don't see any purpose in adding an MX record for each host that
sends email. An MX record is intended as an indication of where to
send mail for a specific domain (destination), not an indication of
'license to send' (as you put it). It has nothing to do with a source.
(Please cite an RFC if I'm wrong on this). chkuser simply uses this as
a (somewhat crude) way to verify the validity of the sender's domain,
in case a bounce message would need to be sent later on.
Adding an MX record to allow a host with a default configuration to
send mail is also dangerous and irresponsible. Giving any ol' server
that can send mail by default a 'license to send email' is not (imo) a
good practice. Any server that's sending mail should be properly
configured, which I don't believe most default configurations are.
BL, these servers in question are problematic because their default
configuration is set to use "acco...@host.domain.com" as the sending
address. While adding an MX record will indeed allow such email to
pass chkuser's filter, this MX record also announces to the world that
mail to host.domain.com is being accepted by the specified server in
the DNS record, which is clearly not the case. I believe that properly
configuring the sending server to authenticate itself, just like
everyone else who submits email, is the best solution.
No, a MX record is not the best choice for Mike's scenario. Don't
confuse this with correct, nor twist it to mean that adding a MX record
for any unconfigured host is correct or implied. We have two issues that
look similar here.
His best choice will be to authenticate, IMHO, and we both agree on this.
RFCs do state that a domain must accept bounce messages if it sends
messages (IIRC, paraphrased). How do I send a bounce to host.domain.com
if there is no MX record? If you're sending as host.domain.com then
there must be an MX record to accept bounces/abuse/postmaster emails. I
may have misinterpreted RFCs here. No, I won't go dig up RFCs on this.
If someone wants to take the time to dig them up then I'm sure we'll all
be appreciative.
(And why should I accept mail for a host that is incorrectly configured
to send mail anyway? )
You're implying that I should change the default settings of chkuser to
allow domains that do not have MX records, to make it easier to accept
mail from servers that are not correctly configured, unless I'm
misreading what you're typing. Seems to me this would cause one (most
likely more) of 3 things:
more spam in everyone's boxes
additional load on spamassassin/clamav
everyone to go and change the tcp.smtp file to turn MX checking back on
IMHO the best choice is to leave it as is, and for those that want/need
it changed to go and change it in their configuration. I'd rather not
change something to make it easier for 10 people, and cause 100 other
people to have to configure their systems to turn it back on. Even if it
is just an entry in tcp.smtp. Not to mention documentation changes,
typo-downtimes, traffic on the list, etc. A wiki page explaining how to
recompile to change this setting seems the best choice for those that
need to change it.
---------------------------------------------------------------------------------
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