On Sat, Nov 06, 1999, Adam Morrison wrote about "Re: mail problem":
> > Just like MAPS RBL and MAPS ORBS.
>
> Actually, it's more of a philosophical question; the MAPS RBL only
> lists IP addresses which are associated with `hard' network abusers,
> ..
This may be a bit off-topic for linux-il, but since people already started
talking about this subject, and as a user of ORBS, RBL and DUL (as well
as RSS) to fight spam, I'd like to clarify the ideas behind using *all*
three lists as a 3-tiered defence against spam.
The idea is that we want to know if the person who sent us the message is
a spammer (in which case we want to junk the message), AND we don't want
him to fooling us by conceiling his identity.
If the message is coming from an IP of a known spammer company, then this is
easy: we'll just junk the message. This is RBL: RBL (Realtime Blackhole List)
is a list of IPs of networks belonging to known spammers, or networks known
for actively helping or harboring spammers.
Now, spammers know people are using RBL, so to hide their identity, instead
of sending you the message directly they send it through a misconfigured
mail server somewhere on the internet which allows "relaying" to anybody.
Properly-configured servers should not allow such relaying. Another reason
spammers are using open relays is cost-shifting: if they can get other
people's servers to send out thousands of messages without an cost to them,
it makes them happier. The ORBS list (www.orbs.org, Open Relay Blackhole
Service?) is a list of servers that are known to allow such "open relaying",
and thus email from them may be untracable and may be spam. Participating
users or systems may refuse email from systems listed on ORBS, but typically
there are a few false positives (legitimate mail is coming from a open-relay
system because that ISP didn't bother fixing their configuration), so it is
recommended to have a list of people that you always want to get mail from.
Some Israeli ISPs, like Netvision and Kavey Zahav (or whatever their name is
now) are NOTORIOUS for trying to cheat ORBS' robots because they feel they
can't be bothered with properly configuring their servers (but ORBS know
they're being cheated, and added these 2 ISPs permanently to their list).
I personally emailed these ISPs myself about the issue, but they wouldn't
listen - apprently they don't care that email from their clients is being
refused around the world, or that they are getting bad publicity (I'm
getting spam delivered through ftp.netvision.net.il at least once a week).
Anyway, once spammers realise that people have started using ORBS (or RSS),
they tried another method: getting a cheap Internet account from some ISP,
log into it, and run the spam program on that dialup IP line - sending spam
directly from it. What we'd rather have them do is to use their ISP's mail
server for relaying the spam. Why?? Because this gives their ISP two chances
to fight them: 1) ISPs can implement limits on their relays to prevent to
many messages being sent from a given IP at a certain interval, for example
2) ISPs can claim this is a misuse of *their* server (if it is specified
in the contract) and sue the spammers. So, if we don't let spammers send
mail from Dialup IPs, we're giving the ISPs ammunitions to fight the spammers
that are abusing them. If these ISPs choose not to fight the spammers on
using their services, then this is fine, but such an ISP will find itself
on the RBL list (see above).
To summarize, the 3-tiered blacklisting is not about 3 levels of "confidence":
only using these 3 together will let us make spammers and spam-friendly
system administrators accountable for their actions.
> that isn't what always happens. Theoretically, users of the DUL accept
> the fact that they won't receive email from dynamic IP addresses. But,
> as we've just seen, not all dynamic IP users are spammers. I think the
> DUL is an inferior solution. Who says dynamic IP email is bad? What
Someone has already posted here the correct explanation for why dynamic
IP email *IS* bad, even when not considering the spam accountability issues
described above: it is very often the case that remote mail servers suffer
from lapses of inavailability: either because of network connectivity
problems, because of shutdowns, and so on. Mailing list administrators are
well aware of the fact, and you usually see messages hanging around for
hours in the mail queue waiting to be sent. Anyway, when you send email
directly from your dynamic IP, and the remote server does not answer, what
do you do? You shouldn't give up, because the server may be temporarily
down, but you can't retry later because the user may disconnect the connection
to the ISP in a minute! The solution is to send the message through your
ISP's server, which is connected to the Internet 24/7.
> will happen with IPv6? I also think that it's wrong to force users to
> use their ISP's mail hub. (Or worse; invisibly redirect SMTP traffic
> to that host.)
What does IPv6 have to do with these issues?
Blocking direct port-25 traffic is a very interesting anti-spam measure
that I haven't seen implemented before, and while it may sound "bad" and
anti-freedom, I can't see what harm it can actually do to "normal" users,
not spammers.
> will get listed. The ORBS database also lists some hosts which relay
> mail only for e.g. the ORBS test machine, and so are NOT really a risk
> to the Internet. Sites using the ORBS database implicitly choose not
This is not true. A machine cannot "accidentally" relay mail only for
ORBS's test machines, and not to any other machine on the Internet. How
can this happen???
There's a different issue, of second-hand relaying, e.g., some ISP may
have a client using their mail server (smarthost) and that client's
mail server has an open relay: but this issue is solvable too if the ISP
cared to solve it.
--
Nadav Har'El | Saturday, Nov 6 1999, 27 Heshvan 5760
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |A thing is not necessarily true because
http://harel.org.il/nadav |a man dies for it. - Oscar Wilde
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
