This and the next message will be the last I'll send to the list on this
topic, as I think we're getting away from qmail. I'll be happy to
continue discussion off-line, though. (Warning: I'm laggy about answering
e-mail quite frequently.)
Racer X <[EMAIL PROTECTED]> writes:
> "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.
I'm not so certain adding a new type of account is that lightweight of an
operation, given the numerous different places in tracking databases that
such information may have to be maintained. But you certainly know more
about that than I do. It's *really* good to hear that Radius makes this a
lot easier from the technical side than I thought.
> 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.
But blocking outbound SMTP connections doesn't seem to serve much purpose
unless you also do spam filtering, or am I missing something? Is there a
practical difference between letting customers spam directly and letting
customers spam through your mail relay apart from the utility of having a
choke point where you can track and cut them off?
> 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.
I had assumed from your previous message about the reasons why you use a
relay machine rather than letting customers send mail directly that you
were doing some sort of spam prevention or backoff on that relay.
(Backoff may not lose legitimate mail, unless the person is trying to send
so much mail that it exceeds the queue period.)
> 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.
Yeah, I understand that. I think it really, really sucks from an abuse
prevention perspective, though. More even than letting people play
whack-a-mole, it means that the obvious solution is to start maintaining
shared blacklists of customers and credit card numbers, a solution almost
worse than the disease from some perspectives.
> 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.
Well, I help run a moderate-volume mail system, and I'd be pretty leery of
saying that about any large mail system. In my experience, there are just
too many things that can go wrong that can cause the person to neither get
their mail sent nor get a response.
There are *many* ISPs who I would trust to provide reliable IP
connectivity but wouldn't want any data I cared about anywhere near their
servers. I know nothing about your business whatsoever, but I can't
believe that feeling's all that uncommon. Networking infrastructure is a
whole different ballgame than system infrastructure.
> 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.
This is the part I disagree with. The skills required in keeping a
network running are more and more divergent from the skills required in
keeping servers running. I'm an amateur network tech at best; I wouldn't
trust me to keep a large IP network working, but I do trust me to keep a
mail system running.
> 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.
Right, understood there. It's just that a lot of people do use dialup
providers as sort of a "miniature" backbone, for sometimes very good
reasons.
> "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.
Less service to the people who want to send mail and can run their own
chatservers? :) (OOC, and feel free to answer this off-line or not
answer it at all, what chatserver did you use?)
> 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.
Definition of trade-off. You're providing less service in one way to
provide more service in another.
I'm sorry to come across as picking on you. I'm really not. I'm being
cynical and grouchy more than anything else.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
