These days I've been unable to find any justifiable need for an unprotected relay of any sort whatsoever.
We do domain hosting and mail redirection (among other things), but we don't do dialup. [...] When they want to send mail out, they have to do it through their IAP's mail server.
As much as it's a small hassle, any user stuck behind a horrible IAP, what about setting the SMTP to the *recipient's* MX host. Since this would be local delivery, would it not be accepted, regardless of source? (The hassle is, of course, changing SMTP for each receipient domain...)
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.
It is crufty, and also crafty. A horrible, but most importantly, effective, kludge. Nearly everyone I've talked to eventually came up with this. It's not the only solution, however, to your particular requirement. Assuming your SMTP gateway is suitably configurable (eg some variant of sendmail or some equally extensible package), you could easily enough set up special rules, on a relay-only box: Call the box "relay.yourdomain.com". Users who use it, configure their outgoing id as "user.name.with.dots.cryptpw@hosted-domain.com". Your ruleset for relay, is to strip the ".cryptpw", do RADIUS-auth on the result with the encrypted password. Iff it passes, relay the mail. (You want it to be used only for this purpose, and only with this mechanism, for greatest likelyhood of avoiding screw-ups.) A simple web interface, with password protection, can give out the cryptpw value, or any other "cookie"-type equivalent. Since your box, relay.yourdomain.com is the SMTP, and rewrites the headers, the "cryptpw" value isn't stored anywhere, and except for routers and any sniffers on broadcast domains (Ethernet or FDDI hubs), nothing will see the packets with this magic value - which is user-specific, to boot.
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.
Open, in this case, is absolute, but there is no absolute closed, only various shades of grey. Any political decision, if made by a reasoning entity, has some chance of being trumped by an adequate technical solution. The only question is what the technical solution costs. I've given it for free; if you use it, please attribute it to me. :-)
We don't use ORBS, either - Alex Rudnev has it spot on, to my mind.
MAPS has both the RBL and RSS - both reasonable alternatives to ORBS. Highly recommended. -- Brian Dickson, Email: briand@teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com
On 01/17/00, Brian Dickson <briand@spare.de.teleglobe.net> wrote:
These days I've been unable to find any justifiable need for an unprotected relay of any sort whatsoever.
We do domain hosting and mail redirection (among other things), but we don't do dialup. [...] When they want to send mail out, they have to do it through their IAP's mail server.
As much as it's a small hassle, any user stuck behind a horrible IAP, what about setting the SMTP to the *recipient's* MX host. Since this would be local delivery, would it not be accepted, regardless of source? (The hassle is, of course, changing SMTP for each receipient domain...)
Spam software has been doing that for quite some time now. That's why so many dialup providers, both big and small, are blocking port 25 at their borders. Yes, I know, clueful people will (a) hate that, and (b) find ways around it, but over 99% of dialup users aren't ever gonna be that clueful...nor should they need to be. ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "I got a machine and took over the world, but nothing changed. | | That would not be fair." | | -- The Violent Femmes | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
participants (2)
-
Brian Dickson
-
J.D. Falk