"Alan J. Flavell" wrote: > 1. Do we have a compelling business case to want to hear from them? > Then don't do callouts on that domain. > > 2. We conclude that they don't participate properly in email, so we > don't want to hear from them. Implement the <> callout, and let them > block their own mail until they learn better. (As you see, this > repairs itself automatically as soon as they start accepting bounces, > without any extra work on our part).
Ah, you folk in acedemia might not then have encountered the argument from a paying customer "I don't care if the admin of the site hosting my prospective customer is a fool, your decision to not accept their mail on the basis of the failed callout is costing me potential business". > It stops quite a number of spams for us, from offering MTAs for which > we'd have no other reason to refuse the item *without* the overhead > of spamassassin rating - which means it's a net benefit to us. I wasn't clear. It did stop several spams from making it to our SpamAssassin cluster, but the overall daily increase n scanning load was less than 5% of one hours load. Your SpamAssassin overhead is nobody elses concern but your own. Don't steal resources from others to make your life easier. If you do, you really are not much better than the spammers that have the same practice. > I'm keenly aware that when the presented envelope-sender is a fake, it > means we're using a (small amount per transaction of) some innocent > third-party's resources in order to keep the spam out. That isn't > nice, really (as Suresh emphasised on this list in the past); but, as > I say, it seems to me that if it's done selectively, it's not too > harmful overall. And in many cases the faked sender is fixed, so, > after being tried and repudiated once, the answer gets cached, and > repeat offerings of spam are refused "for free", without bothering the > innocent third party. And that is a nice intellectualisation. One domain on one of our servers was the target of a joe-job recently. Using the bounce recipients and the originating server as the key to obtain a sample for uncached callouts, the callout load would have only been halved by caching (there were about .5M unique local parts - randomly generated and continuously morphing). That's not a significant reduction. I should point out that the callouts alone from this run made mail unusable for the innocents on this system for unacceptably long. This was not because the callout processing is computationally intenisve, but because they are connection intensive. What I don't get is why you (and many others) think it's OK to: 1. Steal resources. 2. Participate in a DDoS attack (of innocents to boot). By all means use sender callouts on your smart host to verify your senders angainst your MX. Ian -- Ian Freislich -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
