Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Fw: Administrivia: ORBS

  • From: Patrick Evans
  • Date: Sat Jan 15 18:16:47 2000

On Fri, 14 Jan 2000, Greg A. Woods wrote:

> These days I've been unable to find any justifiable need for an
> unprotected relay of any sort whatsoever.  99% of mailers should
> be the final delivery point (or at least the transfer point to
> some private network).  The remaining few are ISPs who need to
> relay from their customers to the world, of course, but so long as
> they don't make the mistake of smarthosting for un-protected
> customer MTAs they can simply block relay by restricting it to
> their own netblocks.  Even most MX targets are the final delivery
> point for the MXed domain.  The real problem is that people are
> still installing mailers that do unprotected relaying by default.
> 
We do domain hosting and mail redirection (among other things), but we
don't do dialup. Every single one of our customers has to use a
third-party IAP for their general net access. Whether they have basic
mail redirection or pop3 mailbox on our server, we only provide
services relating to incoming mail. When they want to send mail out,
they have to do it through their IAP's mail server.

All fine and dandy, in theory. It's not unreasonable for them to want
to send mail out as them@their.domain, and any sane mailer will let
them do it - the problem is with the relay itself. Some IAPs don't
permit any mail to be sent out through their relay unless it's
something@the.isp. Others, most notably AOL, don't let their customers
use any mailer other than the one they supply, and that forces them to
use their assigned email address rather than the one they want to. "So
what if it's valid, it's not our problem", say the IAPs.

This leaves us in a tricky situation. Do we start doing dialup? It's
not worth our time - I've been in that market before, and it's a royal
pain in the arse - not to mention that the vast majority of IAPs here
don't charge a penny for their services, and there's no way we can
compete with that. Do we tell the customer to change ISP? Not only do
they tend, like all users who don't quite understand the situation, to
view it as a limitation of our service rather than a restriction
enforced by their IAP, but we have by no means an exhaustive list of
IAPs which restrict what they will and won't permit to be sent out
through their relays, even if from their own IP ranges.

The only thing we can do which allows all of our customers to send
mail out with their address as the From: header, and not force them to
use our dialup service (if we had one) is to run a completely open
relay. POP before SMTP is a crufty hack, IMNSHO, and SMTP auth isn't
implemented to enough of an extent that I'd be comfortable running it.

Anyone who says there's absolutely no reason to run an open relay is
talking absolute codswallop - as with every situation like this it
requires a reasoned political decision at the site in question. Our
solution? We run a closed relay and hope our customers understand the
situation if they run into problems. On the whole, they do...but we've
lost a few as a result.

We don't use ORBS, either - Alex Rudnev has it spot on, to my mind.
Oh, sure, our customers would be grateful if we could stop them
receiving so much spam, but what do we say to the customer who can't
receive an important email just because we're blocking the sender's
mail relay? That'd be an ex-customer, very quickly.

Watch the customers leave until the only ones we have left are the
ones who don't care whether they receive email or not? An interesting
business plan - don't think my bank manager would go for it, though.

-- 
Patrick Evans - Sysadmin, bran addict and couch potato
pre at pre dot org                     www.pre.org/pre






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.