> | I don't recommend that anyone run an open relay and I'll continue to tell
> | people not to and to refer them to FAQ 5.4, but I'm becoming increasingly
> | sympathetic to people who think they need to. Whether the problem can be
> | fixed without some kind of username/password authentication in SMTP I
> | don't know, but I think it's something worth talking about.
>
> Probably the easiest solution is an applet on the PC that tunnels
> 127.0.0.1:25 to a private smtp or qmtp server on the mail host, doing
> authentication in the process. SMOP. Wasn't there a usenix paper about
> this a while back?
Bingo! This solution allows all dumb MUAs to function, as well as
unattended server scripts. On my laptop (running Linux), I use an ssh
tunnel to relay my queued mail. It's secure and it uses data compression,
so my mail is sent more quickly. I'd be more than happy to describe my
setup for those that want to emulate it.
What's needed for Windows is a simple, but configurable program that
runs on the user's machine and listens to localhost:25. This program
waits for the user's MUA to send mail and then initiates a connection
to the mail relay, authenticating in the process. I could write this in
Perl, but that would require users to download and install ActiveState's
Perl for Win32 on their machines. Anyone interested in writing a little
executable?
We all agree that the ony solution to provide service for users and
not to spammers is authentication before allowing the relay of mail.
Since there is no standard (RFC) for this -- and even if there was,
there would be many MUAs that didn't follow the standard -- the only
solutions are a) to authenticate to server and then allow relaying
for a certain amount of time (e.g. POP before relay), or b) taking all
the dumb MUAs out of the loop by intercepting the sending of mail.
Implementing BOTH is the best solution, IMHO, but a program has yet
to be written to do the latter.
Glenn Strauss
<[EMAIL PROTECTED]>
