On 20/10/2012 18:27, Mike's unattended mail wrote:
On 2012-10-20, Jeroen Geilman <jer...@adaptr.nl> wrote:
DNSBLs are recommended by just about everyone who is serious about
email,
There are a couple ways to use DNSBLs. There are those who are
"serious" but either incompetent or on a cost-saving agenda, and then
there are those who are "serious", and have enough budget to use
DNSBLs competently.
The incompetent use of DNSBLs:
This group uses DNSBLs as originally intended - to *block*
connections. This reckless approach (in effect) guarantees denial
of service on the sole basis of IP address, neglecting more
effective criteria. Not only is the judgement as to whether the
message is spam or ham cheapened, it violates EFF principles.
The competent use of DNSBLs:
This group uses DNSBLs not to block, but rather to aggregate DNSBL
tests with other more effective characteristics of the message.
Instead of foolishly allocating all weight of the message treatment
to one single factor, the finding is appropriately weighted with
other factors. And even if the message is judged to be spam through
a more careful process, /it is still delivered/, and rightly so.
No, it isn't right to deliver spam. Spam should be rejected, because if
it isn't then the sending server has no incentive to clean up its act.
Of course, it's reasonable to argue that spam should only be rejected if
it is 100% certain that it is spam. There certainly are situations in
which false postives are completely unacceptable[1], and the mail system
should be configured to avoid them. But not all spam detection results
in false postives. And not all circumstances require 100% accuracy;
there are many cases where there is an acceptable level of false positives.
Remember that the destination email server exists for the benefit of the
recipient, not the sender, and if the recipient is happy with a few
false positives, or with spam either being rejected or routed to
dev/null, then that is absolutely acceptable. There isn't a generic
right to be able to send email to someone else and insist that it is
delivered.
[1] In the EU, for example, ecommerce operators have a legal obligation
to be contactable by email by their customers. I think that does impose
a consequential obligation to avoid any false positives in their spam
filtering, as otherwise if they rejected an email from a customer and it
caused the customer financial loss as a result then they would be liable
to compensate the customer for that loss. But that's a fairly small
subset of all email recipients, and no such obligation applies to anyone
else unless explicitly imposed by law in the same way.
Keep in mind that the OP called for the "ultimate" mail server, not
the cheapest one. To me this implies that quality *trumps* revenue
and cost-savings (as opposed to being one of many profit-driven
factors).
and a proper EHLO is actually an RFC requirement.
You should read the requirement. The RFC certainly does not insist
that senders buy a domain name.
Who said anything about buying a domain name? Any server connected to
the Internet can have a host name, even one provided by the supplier of
their connectivity rather than themselves.
The RFC allows for senders who do not
own a domain name to supply their literal address (aka IP address) for
the EHLO. Such a message is RFC compliant, but blocked by those who
are uninformed about this and implement reject_non_fqdn_helo_hostname.
It is indeed a common misconception that the RFC requires a hostname
for the EHLO.
I may be wrong, but I don't think that reject_non_fqdn_helo_hostname
will reject an IP address EHLO. At least, the implication of the
docuementation is that it does not, since it says that it enforces the
RFC requirements and, as you rightly say, an IP address is compliant.
But it will reject a non-FQDN hostname that is not an IP address, and
rightly so.
Of course, an IP address in the EHLO is a very strong indicator of
spamminess, so even if it's accepted then it will be one of the factors
that is used, along with others (such as content analysis and DNSBLs) to
determine whether to accept or reject a mail. And, even if it isn't
spam, it is a near-100% indicator of incompetance on the part of the
sending system's administrator.
Mark
