No need for new protocols, closed networks etc. Maybe a need for some
RBL listing virus/spam infected machines, I don't know.
Third-party RBLs are a really, really, really bad idea. They should
categorized as Worst Practices.
... and then refuse to accept any new connections from that source IP
period of time.
Is this the reason for your rational RBL being really bad?
No, they have nothing to do with each other.
Thats the problem there is no reliable way for SMTP at the protocal to
determine if a system is a spammer. But even it did and you automatic
What period of time is this? And how to you correct yourself? How
system report you that it is fixed itself?
My guess is that an appropriate period of time would range from several
hours to a day or so. most mail is retried for a few days, so as long
as the problem is fixed then legitimate mail should be able to get
If anything, I suggest that we take what is REALITY and help
by cleaning it up with reason response codes and also maybe, if
consolidate the sites.
You say the world REALITY as if it were somehow inherently desirable -
or at least, not subject to change so we might as well accept it. Of
course there are many things that are common in reality which are not
desirable - like drunk driving and the use of lies to justify killing
thousands of people with warfare. (which is far as I can tell is the
norm rather than the exception)
Our criteria for initial standardization say nothing about reality -
they do say things like "no known technical omissions".
REALITY is that RBLs block legitimate mail and contribute significantly
to the failure rate of the mail system. And no, we shouldn't
standardize that part of reality.
Some systems may want to just block up dialups or
open relays but not mailing list with no subcribe confirmations.
look at some of the response tables for the RBL sites.
Again, if a site that owns its IP block says "only these machines can
send mail from this IP block" (by putting appropriate records in the
right in-addr.arpa zone) I'd consider that reliable. If some third
party makes a similar statement about a source IP address, you have no
way of knowing whether that is reliable.
1) RBL are the BEST thing and ONLY thing available to makes the
That reminds me of the tech support guy who realizes that his problems
get more managable if he leaves his phone off the hook. Perhaps this
is the norm, but it's not worthy of standardization.
Lets face it, the suggestion of throwing away the idea of RBL is not
reality or categorizing it a WORST PRACTICE is not going to stop it
being used until you offer something that replaces it with the same
Perhaps, but we don't need to bless it. I'm all for encouraging
reliable ways of detecting or discouraging spam. Especially those that
don't impair the flexibility of the mail system.
I agree. But Keith until SMTP provides a standard and reliable way to
this at the protocol level, RBL will remain to be the top method of
spam. They work!
They also make email a lot less reliable. Of course, you are correct
to point out that they are popular.
Face it, there is no reliable way to detect spam at the protocol level.
There is no reliable way to detect spam even if you look at the email
message. Spam is contextual. In effect, people are demanding that the
mail system read their minds and _anticipate_ what they will object to.
There is no technically sound way to do this.
There are however things we can do to discourage spam without impairing
reliability. One is to make mail more traceable - thus making it more
difficult for spammers to hide. I think it can also provide a way to
immediately report to a network when a system on that network is
propagating a virus. Another thing that will help is to make it more
difficult for spammers or viruses to use random systems to propagate
mail. We can define a way to allow recipients to specify criteria for
mail that they don't want to receive.
What I'm proposing is that we encourage measures like this - that are
based on information from reliable sources - as alternatives to some of
the less reliable ad hoc measures that are currently in use.