Domain: elysium.pl
Stories and comments across the archive that link to elysium.pl.
Comments · 10
-
Re:Yeah, but...
Not quite running Linux, but with one central Linux servers and a bunch of C64 terminals, you're almost there......
http://members.elysium.pl/ytm/html/linux-term.htmlBut you can run Linux on several models of the Amiga. http://www.anytux.org/hardware.php?baureihe_id=137
Or maybe you can find another old computer model that you'd like by browsing this list: http://www.anytux.org/hardware.php
Layne
-
Re:What is the best way to stop this?
- ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
- IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
- SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
- E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.
Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for: -
Re:*sigh*
Now that I found some documentation for GEOS I'll get right on it. Might have to dust-off the ol' 512K RAM expansion cart, though...
-
advice from the front linesI am in the process of doing something very much like building a custom laptop, but I'm afraid I don't have very good news: it will be expensive, time consuming, and you will need to make many sacrifices.
If you check out my journal you will get a detailed description of what I've been doing and why. In a nutshell: I'm trying to build a handheld computer that delivers adequate performance with maximum flexibility and battery life. The target design will have a small (7-8 inch) VGA screen, a moderately slow processor (100-200 MHz ARM), moderately sized hard disk (10-20 GB, 2" IDE), a moderate amount of RAM (32-256 MB), and run off of conventional rechargable batteries (8 AA NiMH cells) for at least 8-hours on a single charge.
Just to build the prototype will take several months and cost at least $1000 (probably several times that, when all is said and done). If I go to production, I can probably get the cost down to $300 per unit (not counting NRE costs), but the selling price will still be up in the $500 range.
The only way I am able to do any of this is that I am abandoning any kind of PC compatability: This device will never be able to run Windows or play flashy games (though it will run a regular, non-embedded, version of Linux). I've had to give up on all kinds of features that seemed like they should be simple: I don't have a clamshell case because the engineering is too complex for me to do myself and I don't have a keybaord because I couldn't find a source for laptop-style keyboards. I'm still holding out for polymer-LiION batteries, but I haven't found anywhere that builds them on contract, yet.
This is not the same sort of task as building a desktop computer from white-box parts (which is only slightly harder than plugging together lego blocks). This is much closer to actual engineering: I'll be constructing some of my own breadboards to connect the SBC to the LCD and the IDE hard disk, as well as custom hardware to charge and monitor the batteries.
-
Re:No, no, no... look at this another way
The only solutions here are some sort of VPN to the network where my SMTP server lives (at work), or else ssh to the SMTP server (which is what I actually do, but it's inconvenient).
Exactly. The admin of the SMTP server you want to use ought to use SMTP + AUTH + SSL, which would run off another port (SMTPS uses 465). So the SSL part takes care of the issues with your ISP (they won't be blocking port 465). The AUTH part keeps your work SMTP server from unauthorized use (e.g. spammers looking for an open relay). Everyone is happy. Here are some links with additional info on setting up SMTP + AUTH + SSL: -
Re:Hidden Features
There's no need to open holes in your relays,
use authentication, either SMTP-AUTH or POP-before-SMTP(nicely transparent to most mail clients).
anyway, is there a real reason not to use the corporate servers? -
Filter egress port 25!!
If you are running a network, it behooves you to filter outgoing port 25. SMTP is a lousy protocol, and there is no successor to replace it (anytime soon).
E-mail server admins: Please lock down your servers! Only allow initial mail submission by authorized and authenticated clients, and only allow such subissions on a port other than 25. It's not that tough, and it's your job. Do it.
There, no excuses.
-
I don't think you get it
I don't think a lot of readers are understanding the idea suggested in the original post. If you are an customer of a dialup ISP, use that ISP's SMTP server-- only. If you want to use someone else's SMTP server (including your own that you set up somewhere), then that SMTP server ought to be configured to accept initial mail submission on a port other than 25. Your "rank and file" customers will not have a problem with this-- they will continue to use the ISP's SMTP server and all is well. For those "power users" (define as you like) that have a need for external SMTP servers, well, have them do the work (sorry-- life sucks sometimes). The ISP posts a page explaining why port 25 is blocked, and suggests using alternate ports (e.g. 465, SMTPS).
If you are the admin of an SMTP server that external clients (i.e. unknown IP addresses) will connect to for intitial mail submission, you are doing the Internet (and your users) a disservice if such connections are allowed unauthenticated. Sendmail, QMail, Exchange (gasp!) all can be configured to require authentication for initial mail submission. Use SSL as well, and you will probably be using another port (465). Spammers are not going to port scan for a way to send mail! Admins-- get off your butts and secure your servers, or else you are part of the spam problem. Please don't gripe about how following industry standard practices for securing a publicly accessable server makes your job more difficult-- that is your job!
-
Re:Not a troll, but
-
Re:I see his point though...
My problem is that SMTP has no authentication that I can find that would allow me to let him use our SMTP server from wherever he was
Yes it does. Read RFC2554, SMTP AUTH. To quote: "SMTP AUTH is "
..an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions."