On 2012-10-21, Mark Goodge <m...@good-stuff.co.uk> wrote: > > 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.
How does a rejection create incentive for a spam-sending server to clean up? If this is a botnet node w/ unwitting sender, then the malware simply continues on. If it's the sort of spam that is sent deliberately by someone who is in control of their server (e.g. spam from a legitimate commercial entity), then they're not generally using a method that results in a DNSBL rejection to start with. > Of course, it's reasonable to argue that spam should only be > rejected if it is 100% certain that it is spam. Bingo. Precisely the problem. It's impossible to have any certainty at all using a DNSBL in a way that is blind to the payload. This requires using the DNSBL in a more sophisticated manner. > There certainly are situations in which false postives are > completely unacceptable[1] For me, all false positives /that result in non-delivery/ are completely unacceptable. Of course false positives are unavoidable, and so acceptable as long as the message is properly delivered. > 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. When a crude technique is used, like taking IP address as a sole-factor, this obviously gets a relatively poor false positive rate. And it's not just a poor rate with respect to the more intelligent approaches, it also does unacceptable damage because of how it acts on positives. > Remember that the destination email server exists for the benefit of > the recipient, not the sender, Indeed. So when the sender tells the recipient to get an email address that works (that is, one with an MX server that will accept a legitimate RFC-compliant message), then the recipient is put in a situation of having to find something that suits their needs. > 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. Agreed. However, generally recipients are *unaware* of how their mail is being handled. Rejecting messages without the recipients knowledge or consent is socially irresponsible and totally unacceptible, per EFF principles. > There isn't a generic right to be able to send email to someone else > and insist that it is delivered. I hear that such a right exists in Germany. Rumor though. I didn't verify it, but supposedly there is a generic prohibition on interfering with communications. >> 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, If you use the FQDN format for the EHLO, it cannot be just any FQDN. The RFC requires that it is a /resolvable/ FQDN of the sender. So the RFC-compliant sender /must/ have a FQDN (if they use the FQDN format), and the FQDN is not free. > even one provided by the supplier of their connectivity rather than > themselves. Sure, a supplier might have an FQDN, but then it's the senders FQDN that is used, and the supplier must subscribe to that FQDN. This doesn't change the RFC obligation of the sender, it just shifts who the sender is. If you don't have a FQDN, and you do not contract the service to another third party, then the only way to send an RFC-compliant message is to use an address literal 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. Well I understood reject_non_fqdn_helo_hostname to reject all EHLO IPs and all non-resolvable FQDNs, and possibly also resolvable FQDNs that do not appear in the senders address field. If you're correct, then it doesn't have the problem that I thought it had. Certainly there are servers that are as aggressive as I stated, but perhaps it's options that I confused with reject_non_fqdn_helo_hostname that are responsible. > 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. Indeed. And that's fair enough. It's what I described a competent use of DNSBLs. > And, even if it isn't spam, it is a near-100% indicator of > incompetance on the part of the sending system's administrator. How do you think a competent sys admin sets the EHLO under the circumstances of not buying a domain name, and not establishing a business relationship with a third party? The RFC only permits one way, and that way is obviously the competent way (unless you would argue that it's not competent to adhere to the RFC).
