It's really very simple ... enough to cause ISP techies to tear their
hair out by the roots and root directories by the dozens.
If and when a standard is finally pushed down the throats of the
majority of ISPs, it appears that Arachne should have no problem
complying.
Certain "watches" are already in place on some smtp servers; the freebie
places often want you to download mail before you upload any. The
ability to successfully download mail tells the server that you have an
acceptable user/psswd pair, and it then allows you to send mail in the
same session.
This new system uses the equivalent of "cookies & cream" to authenticate
users who wish to send mail. Instead of simply asking you to login and
provide a password, the system sends a string to your browser, and you
browser is expected to reply with another string. The "cream" part?
Both the inquiry & response strings are Base64 encoded. If you pass you
get to send mail.
What I could not find addresses is one little bitty teeny weeny thing:
An explanation of how either string is generated, or where it will be
stored in the browser.
If someone wants to read further and try to figure it out, fine. The
link Glenn provided is just the discussion and NOT the final approved
rule.
The problem I see with this are: There MAY be something very similar
to [but not the same as, since that's another layer that *can* be added
in] "secure pages"; the browser may need a "key" built in which responds
appropriately to various encoded strings sent.
Now if the foregoing happens, there really isn't any authentication. If
a "key" generates the appropriate answer, then any browser with the
:key: could access any smtp server.
What I *hope* is the case: Every ISP has its own "mini-key" that is
issued to users as they sign on to the service [or existing users as the
system is brought on line]. That 'mini-key' will respond appropriately
to the encoded string sent by the smtp software, and the session will
then begin.
What Arachne will have to do to be in compliance:
a. Be able to recognize the encoded string as a command requiring a
response
b. Determine which server sent the inquiry [in the case of having more
than one ISP one uses] and reply with the appropriate ISP specific
string.
If it requires decoding and encoding, that's already built in.
Now, if the individual with the ISP that requires Authentication could
get the ISP to cough up whatever is required on the USER end to comply,
we might be able to figure out just what in the heck is really going on
here.
*IF* no computations/re-encryption is actually required, if only a set
string response is called for, then maybe it could be possible to -- as
a temporary fix only -- provide an option of handling smtp logins in
"terminal mode" so that when the string is sent from server, the user
could then respond with the appropriate string [by importing a file that
has only that string in it???] to complete session onload. Once session
was open, then Arachne could go back to auto-send mode and let the USER
catch his/her breath.
What they want to do is simple. But I think it simply *won't* work. If
set strings are required as responses, creeps will acquire those set
strings. If a whole module is required in the browser to decode,
interpret, recode, respond then the creeps will reverse engineer that
and put it to work for them.
I really think the best way to control who sends mail from a server is
on the receiving end. If ISPs decide to refuse all mail sent from ISPs
with open relays, those ISPs will either go out of business or put up
the firewall that should have been there in the first place.
But what may eventually be required:
Relay servers are essential to moving the mail. The reason the internet
works is because there are so many servers available to relay and no set
path ever followed.
The ISPs may need to set up the "authentication" system so that their
mail from their servers is forwarded to the next available relay as
"good to go," while those who maintain the relays would authenticate the
mail as it came through ... failed authentication = bit bucket.
IMNSHO,
The individual, whether user or abuser, should be under the "control" of
the ISP. The servers belong to the ISPs and they're the ones that need
to make certain THEY are not allowing abusers to use them.
l.d.
====
On Wed, 11 Oct 2000 23:17:49 -0500, Glenn McCorkle wrote:
> OK folks.
> Volunteers are now needed to:
> 1) read
> 2) decipher
> 3) explain in `plain language'........
> http://www.cis.ohio-state.edu/htbin/rfc/rfc2554.html
-- Arachne V1.66, NON-COMMERCIAL copy, http://arachne.cz/
