Jake Vickers wrote:
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.
Good. I guess I'm not seeing the 2nd issue.
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? )
I agree.
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
I certainly did not mean to imply such a thing. I don't think that
changing chkuser settings to accomodate a misconfigured server is a good
practice.
At the same time, if someone wants/needs to do such a thing, I think
that QMT should accomodate it in a simply way. What I'd like to see is
chkuser compiled with its default settings, but with the
CHKUSER_SENDER_MX setting specified in the tcp.smtp file for the 'stock'
toaster. This would allow someone, however ill-advised, to change the
setting without having to recompile the source code. That's different
than recommending the non-use of this setting.
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.
Once again, they cannot change this without recompiling. This can be
made this easier to do.
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.
This can be done w/out causing anyone to turn it back on. A little
scripting in the %post section would do the trick.
It's up to you though. Perhaps doing something ill-advised should be
difficult to do.
This whole chkuser situation will likely become moot in the future
anywise, as spamdyke will possibly take on all of chkuser's functionality.
--
-Eric 'shubes'
---------------------------------------------------------------------------------
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
