>> Wrong. It simply requires you to use Radius and network equipment
that
>> allows you to send back filters in your Radius authentication.
>
>Good, I'm glad to hear that it's improved. (It certainly used to be the
>case that this was hard.) So how many ISPs are going to be willing to
do
>this? The cost that I was talking about is not only programming effort
>(thankfully apparently not an issue) but also administrative overhead.
>(See below.)
FYI, it's fairly straight-forward if you use a halfway-decent Radius
server (that is, not stock Livingston or Ascend) and a backend database
for accounting. We use Radiator, a Radius server written in Perl, and
Microsoft SQL 6.5.
"Administrative overhead" is not a valid point. Any ISP with more than a
handful of accounts will have different types of accounts they sell.
Static IP, ISDN, POP only, hourly rates vs. fixed rates... Adding a rate
class for "relay permitted" is no more bother than any of these other
accounts.
>No, I disagree, because any measure that you use to prevent the crap
from
>going out in the first place *will* result in loss of legitimate mail.
>This is the inherent problem with spam filtering, and is something that
>Dan's been rightfully pointing out on this list for a while. I *do* do
>spam filtering, but solely because there's currently no better
>alternative.
Spam filtering may well result in the loss of legitimate email. Blocking
outbound SMTP connections will not, as the mail will never be sent in the
first place. The sender is clearly aware of the fact that his mail did
not go out. This is very different from seeing mail acknowledged by the
remote server and then having it mysteriously disappear due to a spam
filter.
Let's keep these two techniques distinct. I am pretty opposed to doing
any kind of filtering after a message is received, but I'm not so opposed
to refusing connections or sending back an error code to mailservers I
don't like.
>The only *real* solution is to provide sufficient economic or legal
>disincentive (because that's the only thing people actually listen to)
to
>stop spamming in the first place. Cleanup charges, laws that allow
people
>to collect damages... that's what's going to make it go away. But in a
>world where ISPs routinely give out free trial accounts and certain
large
>ISPs refuse as a matter of policy to even check credit card numbers to
see
>if they belong to people who were previously kicked off for spamming,
>trying to do anything *real* about spam is almost a lost cause.
ISP's don't give out free accounts as a matter of policy; they do it
because customers demand it. To be competitive in our marketplace, we
HAVE to let customers give our basic service a trial before they commit
to it. This is something that a large portion of our customers have
demanded before purchasing from us. If we refuse a free trial they will
go to someone who will give them one.
>If you want to turn on port 25 for certain customers on a customer-by-
>customer basis, you have to implement some sort of tracking for those
>people, and a procedure for them to get approved, and....
See above. This is not a major consideration assuming you already have a
generic billing/accounting/tracking procedure for other types of
accounts.
>Like I said. And there are a few people who just want to be in control
of
>their own mail. I know I would. I know lots of other people feel the
>same way. You may be a great, well-run, reliable outfit, but the fact
>remains that computers fail and things go wrong, often at the *remote*
>side, and unless you're running your own outgoing mail, finding out
about
>it is a crap shoot.
If you're purchasing service from us, that's an implicit assumption that
we provide some sort of reliable service. Perhaps it's not guaranteed or
insured, but you can assume that either your message will go through or
that it will be returned to you with some sort of error code.
If you DON'T trust us to handle mail correctly, then how do you trust us
to handle your network connectivity correctly? I realize the two things
are different, but if you trust us to give you an IP address when you
want it then it seems you should trust us to send your mail for you.
If this isn't the case, you can lease a line from a backbone provider and
do whatever you want. We make no bones about the fact that we are not a
backbone.
>I'm sorry, but this is simply not true. Less is not more. You're
>providing less service. There's no way to get around that. I'd be a
lot
>friendlier towards people who feel that the realities of spam are
forcing
>them into doing port blocking if they'd quit trying to misrepresent it
as
>a "feature."
"Less service" to whom? Because of the time we saved tracking down spam,
we were able to bring up a chat server, which our research showed was
much more in demand than being able to send outgoing email directly.
It's a trade-off, sure, but we've made more of our customers happy with
the trade-off. I don't see how an ISP can operate any other way, and I
don't see how it's providing less service.
shag
