I could list a number of sites, (northgrumm.com et al AeroSpace/DOD clients) where the first step, in security, is to block port 22. In fact, to block ALL encrypted traffic. Those guys see that as a National Security and contract requirements issue <grin>. Those same outfits ban radio xmit/rcv at the guard shack<g>. For other, more civilian organizations, we frequently work with groups that have SA staff that considers that the first step in security is to cut the connection altogether. Failing that, blocking all ports, on all hosts, is the next reflexive step. Eventually, we get down to required ports and proxy servers. The bottom-line is that we've had to go as far as running a VPN on port 80 and that only works if there is a direct path (no proxy). In many organizations, a system isn't considered secure unless port 22 is blocked, at the firewall. It is, after all, the secure port, that must mean that you have to block it to be secure, right? In this sort of environment, we don't usually get assigned internal email accounts, we have to use our own. However, they usually allow proxied port 25 and 110 access but the source address is still theirs. Yes, I already use F-Secure when I can.
From: Dana Hudes: Saturday, July 08, 2000 9:55 PM
The solution is not to open relays but to use an IPSEC tunnel into the internal network. Or you could use SSH port forwarding to accomplish the same thing. If you open relays, the spammers will find and abuse them. IPSEC clients and servers are available commercially. Nortel Networks Contivity Extranet Gateway is one, and Nortel use it themselves. Shiva have a similar product.
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com> Sent: Sunday, July 09, 2000 12:24 AM
Roland (first off, you're missing an 'e' <g>),
I agree. MHSC lost an entire market plan, hosting third-party secure mail, becasue third-party mail services must allow relaying that is at minimum semi-open. At the time SMTP AUTH didn't exist (Until it's use becomes more wide-spread it still isn't real useful). The anti-relay bunch are killing a valid business model. Even for internal use, we have staff, on client-site, that need to send/recieve their mail from our servers, even when their lap-top is DHCP attached to another net-block. Every week we find ourselves having to open the relays more and more. Next week, I am travelling to the EU on business. That's yet more net-blocks that I have to allow relaying from.
A single ORBS forged header, with the right source info in it, will pass right through our mail system, like it was greased. The whole anti-relay jihad is a fallacious rat-hole populated by rabid self-righteous rats who don't have a clue. If they don't need it then it must not be a valid feature <humph!>. ORBS itself should be RBL'd, IMHO.
Using the same sort of mind-set to subjectively BL script-kiddee networks is dangerous, as the ORBS bunch has shown. It is all too easy for it to get out of hand, vigilante-style. What are the criteria and who has the over-sight?
That said, having had a few of our production hosts "owned", by mwsh in the past, I am NOT fond of script-kiddies and agree that something needs to be done. But, I am seriously resistant to yet another ORBS style regulator bunch. That is NOT the answer. Please, let's all look for another solution.
--- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer
rdobbins@netmore.net: Saturday, July 08, 2000 11:03 AM
ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing.
The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of
encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP.
POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well.