Branden Robinson writes ("Re: Ian Jackson, please get me the hell off your blacklist."): > I see no reason not to reply [...]
I think you are being hypocritical. You complain when other people post their opinions and discussions of this topic with you, yet you post your own diatribes here. Since your request to keep the discussion to private email seems insincere I shall answer you here. Also, I object to your misleading characterisations of my position and highly tendentious phrasings in your complaints. They are not helpful for constructive debate and I respectfully suggest that you tone it down. As I said in private email, I understand that you're angry, but please stop acting out. There are two issues here. One is the general question about mail handling, spam blocking, etc. The other is the specific issue with respect to your complaint about my mail system. On the general question: I think it's completely unhelpful when people on both sides of this argument start to talk about how it's their `right' to send mail freely in any way they like and have it accepted, or their `right' to block mail in any way they choose. I don't want to get into the existence or otherwise of these `rights' for communications on the net in general. That's just asking for an enormous and pointless flamewar. However, it's clear that for us to work successfully together we must be able to communicate. Every pair of developers might need to talk to each other. It's therefore not OK if due to people's exercise of these `rights' they can't communicate. This obviously means that developers have to have at least some shared ideas of what can be expected from the sending and receiving ends of a mail transfer. The problem is caused by the existence of spam, because it means that there are people who are trying to send mail to us whose mail we definitely want to exclude - and these exclusions are essentially political rather than technical and sometimes have false positives or mean that certain kinds of apparently harmless behaviour end up forbidden. This leads to the kinds of heated debates we've seen here. The upshot is that there will have to be some agreement about what is and is not acceptable, both as behaviour on the part of the sender, or as policy on the part of the recipient. There will have to be some minimum standards (even if they're not written down) which everyone agrees to abide by. It seems obvious to me that we should try to balance the negative effects of spam (and other kinds of abusive or broken mail) and the inconvenience of people having to change mail configuration or whatever to make the mail get through. We can't take this whole issue as a lump and say I HAVE MY RIGHT TO DO WHATEVER I WANT AND FUCK YOU YOU'RE ALL A BUNCH OF ARSEHOLES. Instead, we should argue each issue on merits in a constructive way, in terms of its costs, benefits etc. Several kinds of these issues have been raised: MAPS RBL, MAPS RSS, ORBS, DUL (and the like), and various similar things. I think we should take them each individually. It seems to me that the case for the MAPS RBL and the MAPS RSS are pretty well established; they have very low false positive rates, and are generally careful about who they include. With the RBL, of course, you could even say that it's unethical to financially support a spam-haven ISP. It's true that being (or mailing via) an open relay - the criterion for RSS - is not necessarily evil in itself, but it makes it very hard to distinguish legitimate from spam mail, and in general we are all I think agreed that in today's Internet open relays are a problem which needs to be removed. With respect to the ORBS: I respect what they're trying to do, but it seems to me that they're too quick to list entire networks because they allegedly blocked the automatic tester, and too slow to remove them. This means that a sender can effectively end up with no good solution, merely because someone on a neighbouring IP address once blocked the ORBS tester. I won't go into the DUL here, because that's a very contentious issue and would be too much to talk about in this one message. I'll send another message with my view on the DUL. On the specific issue: Branden's complaint is about the fact that for the first three hours after seeing a particular IP address (or for the first hour after seeing a new envelope sender), my MTA will not accept mail from it. Instead it sends a `450' response to RCPT; this is a temporary failure code which indicates to the sending end that it should try later. Before I go into the details, I would like to point out to anyone else who is reading this thread that Branden did not receive a bounce. Indeed, this strategy by my MTA is invisible to the sender of the mail, though of course it can be visible to their system administrator in logfiles and mail queues. Branden discovered this SMTP interaction by looking at his sendmail logs (NB, not due to an error report from his MTA, just a routine log entry about a message deferral); he saw the `450' message and became upset. Branden claims: Individual users must twist themselves into [a] pretzel [...] to satisfy SAUCE [.] This is simply false. Individual users have to do nothing at all. Branden, as system administrator, saw something in his logs and simply decided to take offence. No investigation, no calm enquiry to postmaster or via a colleague, nothing. Branden's first action was to close all bug reports from any of my users - before a message delivery had even failed ! Branden seem to have two basic complaints. Firstly, he draws a value judgement into this deferral - he seems to feel insulted by the fact that my MTA is cautious, having not seen his IP address before, and chooses to wait a bit to see whether (for example) the address is that of a spammer whose software will not retry, or whose account will be cancelled before the next delivery attempt, or who will be blacklisted by then, or whatever. It's not the case that my software `assumes he is a spammer'; it just wants to wait and see for a bit. This is a highly effective anti-spam tactic which several other pieces of anti-spam software also use. I have made it clear that this is nothing personal. I've also explained that there is no technical problem and that the mail will be delivered. His second complaint is that the 450 response contained the string `[Irritated]' at the end. I think this is probably what got him really upset. However, in normal operation under correct conditions (which includes this case) the user never sees this message at all, just the sysadmin. I think that sysadmins should be used by now to seeing slightly strange and humourous messages in protocol dialogues ! If Branden can't cope with a piece of software suggesting, in a message seen only by sysadmins, that it's `irritated' - in what seems to me to be clearly tongue-in-cheek anthropomorphisation - then perhaps he should get a thicker skin ? (The message `Irritated' does really mean something here. It's to do with SAUCE's teergrube function. If SAUCE needs to issue an SMTP error response, it will pause for a little before actually sending the error response. It remembers for each calling IP address how many errors it has been sending recently, compared to successful responses and successful message deliveries, and calculates a delay for each error response - or in extreme cases each response of any kind - according to a complicated formula. This has a number of benefits. For example it prevents address-testing/harvesting by spammers. Some sending systems will immediately retry the same failed request, and it prevents these infinite loops from spinning out of control.) Ian.