Re: Ian Jackson, please get me the hell off your blacklist.
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.
Reply to: