-----Original Message-----
From: johnp [mailto:johnp(_at_)idimo(_dot_)com]
Sent: zaterdag 24 september 2005 9:21
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Can this really be true?
Mark wrote:
-----Original Message-----
From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: vrijdag 23 september 2005 23:08
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Can this really be true?
johnp writes:
I continue to be staggered by what is basically an open
relay in everyone's home or office in the USA. What other
countries ISP's allow such behaviour?
You are making some wild leaps here. ISPs limiting use of their
relays to their own users is hardly anything like "having an open
relay in everyone's home or office."
Indeed. A relay is ony "open" if people other than your own users have
access to it. I once asked a large ISP here, in the Netherlands, why
they do not enforce SMTP AUTH? The answer was as simple as it was true:
"Because doing so means dealing with 5,000 extra calls to our helpdesk."
Strictly speaking -- except for the size of the user-base, perhaps --
there is no difference between an ISP granting access to its network to
the IP addresses of its own customers, and people not enforcing SMTP
AUTH to folks on their home network.
Customers of an ISP basically can be said to 'buy into' a portion of
trust; should they abuse that trust, then the ISP will typically
terminate their account. Enforcing SMTP AUTH is actually of little
consequence, because the customer who spams is easily identified by his
IP address -- recognized internally, by the ISP, that is; and having an
"authid" in the logs makes identifying that customer only marginally
easier.
So, from the ISP point of view, I actually agree with the position of
not enforcing SMTP AUTH unless you have to; which is to say, when you
need to authenticate people who do not already have access to your
network by other means. Only if you gave people access to your network,
without SMTP AUTH, if they had not otherwise access to it, would you be
an open relay.
So, let me get this straight. It appears that an ISP allows unrestricted
access to SMTP provided the user is logged into the network by a plain
username/password combination which might be encrypted on the ISP's
servers, but is almost certainly stored in plain on the users PC.
I wouldn't say "unrestricted access" per se; more like "provisional
access" -- where the provision is that they not abuse the services.
A lot of customers -- and I daresay the vast majority of those with
highspeed ADSL connections -- log into their ISP using PPPoA, or something
similar, and stay logged in for as long as the connection holds. The ADSL
modem logs in, and the customer has typically no control, at all, over how
the username + password are sent to the ISP.
Why should I bother with authenticating my users smtp log-in with anything
other than POP-before-SMTP? That is similar to the ISP's log-in - a plain
username/password combination.
As long as mail clients like Outlook Express only do "LOGIN" and "PLAIN"
for SMTP AUTH, but *not* STARTTLS, forcing SMTP AUTH, in itself, will not
solve the insecure transmission of username + password combinations.
Unless people make 'stunnel' like connections on port 465.
I am in the position of having insisted on SASL in plain for lots of
clients on port 587, only to find that I might now have to relax that in
order to keep some of my customers because opening the extra 2 windows to
configure Outlook on one occaision is difficult for them, and their ISP
doesn't need that tiny extra bit of work.
The ISP I asked earlier does not even offer SMTP AUTH to their customers'
IP addresses! And that for the same reason they gave earlier: clients who
have SMTP AUTH enabled, by 'accident', might have done so wrongly; hence,
more calls to the helpdesk. :) I tested that; and, indeed, they only offer
SMTP AUTH when you connect from outside the network (on port 25, at
least). Actually, lol, I, and others, got them to finally offer SMTP AUTH
on a special SMTP server; but still not on the default ones (at least not
when you connect from inside the network).
I joined the SPF project because I was under the impression that there was
a definite movement to tighten up e-mail usage.
There is.
I am not surprised to read that around 80% of emails which originate
from SPF publishing domains are SPAM!
http://www.enterprisenetworkingplanet.com/netsecur/article.php/3551246
Good! It means we now have 80% positively identifiable spam domains that
can be blocked without further ado. :) Long live SPF!
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com