W dniu 2009-04-14 23:00, mouss pisze:
Paweł Leśniak a écrit :
W dniu 2009-04-13 22:46, mouss pisze:
does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?
According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name. The consequences of
this are becoming more and more obvious. Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS.
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
(...)
Assuming that spam is a global problem, and above RFC is something to
obey with, it's not really important how many spams we'll block with
reject_unknown_sender_domain.
I disagree:
- I prefer to avoid dns checks if they don't bring me much
Look at numbers below. I think they bring a lot.
- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
Well. it depends on type of service. If I were an ISP, I think I'd take
more care to avoid getting "false positives". As long as these are not
RFC conformant, I won't call them legitimate emails.
- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
Well, I do not agree with that. It's just one more DNS query from my
host. It's far less offensive then sending single email to this site.
- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.
You can't cure all sites your server is talking to. So you have to
choose what you believe is best for you.
If message is blocked with
reject_unknown_sender_domain, it means sender's server has some problem
with DNS configuration. It's of no cost to configure DNS records for
mailserver, and it makes lots less questions to zen. If mailserver's
admin doesn't care about DNS entries I don't feel any need to care about
emails coming from this mailserver.
possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...
But these recipients care about amount of spam they get. If my server
rejects some mails, the other side has to choose if they want me to get
their mail or not. If there are not enough rules to stop spam, we have
to obey with what we have (RFCs).
Fortunately all large public
mailservers we're getting emails from have DNS records set up correctly.
and spammers seem to forge valid addresses, so the check looks useless
to me.
How do they forge a client DNS A records consistent with PTR records?
On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
these also reject legitimate mail. YMMV.
I'd call those "legitimate mail". Server *should* have DNS records. If
client address has no DNS enrtries, it's RFC-ignorant.
In my opinion, *if* one can afford loosing some legitimate mails from
hosts without correct DNS entries, reject_unknown_* rules are worth
using. Still if mail gets rejected, sender has possibility to ask
his/her mailserver's admin to solve the problem.
it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.
I do agree with your last sentences in 100%.
Pawel Lesniak
