From: johnp [mailto:johnp(_at_)idimo(_dot_)com]
Sent: Sunday, September 25, 2005 11:55 AM
Alex van den Bogaerdt wrote:
On Sun, Sep 25, 2005 at 03:10:40PM +0200, johnp wrote:
<...>
It doesn't matter if it is the user itself or a zombie. That
machine is the spam source/is relaying spam. That machine should
be taken out of the network/be isolated.
This is both valid from an SPF standpoint and from an anti-spam
standpoint.
I am not defending ISPs that do not combat these kind of users.
However, there is, IMHO, no need for an ISP to use password based
authentication if they are doing source address based authorization
(PVC, ip address, whatever).
Am I missing something here? How can they verify *anything* about
an attempted connection to their network except by username/password.
After they have confirmed the authenticity of the login, they then
allocate a dynamic IP to that user. After that they are into
policing policies to control spam by volume, rate, whatever.
I think you are both saying the same thing, but from different perspectives.
The local ISP really provides two services for the customer: internet
connectivity and mail relay. There is a slight difference between these two
services. Internet connectivity is only available from fixed,
pre-established locations via DSL, cable, leased line, microwave relay, etc.
Though some connections are so hard-wired that no authentication is really
needed, it is easier to require all clients to authenticate in order to
connect to the network and access the internet. Mail relay, however,
_could_ be used from any location where the customer can get or borrow an
internet connection. That is the justification for two separate logins. If
all customers only used the ISP's services from their fixed location, and
they each only had a single mail account, the network login by itself would
be sufficient to grant them the right to fetch and submit mail.
Most of the time, neither of these assumptions is true. There are usually
more than one email account per network connection point and users want to
submit mail while not connected to the local network. In a
pre-domain-authentication environment, i.e. today, the roaming user can
usually just submit unverified originator addresses to the foreign MSA on a
guest account, as long as there was a proper network login for the physical
connection point, and the MSA will accept it. When originating domain
authentication becomes more common at the recipient, this arrangement will
no longer work. ISP's who don't provide SMTP-AUTH today tell their
customers who roam to use webmail, but that doesn't work well for people who
travel a lot.
The motivation for providing SMTP-AUTH is that the user authenticates the
same way both from their fixed network connection and while roaming. A
secondary motivation is that by enforcing submission rights (including
From:), they make phishing from their MTA very difficult and end-user abuse
reports will more often go the right place. This is obviously a situation
where the number of ISP's who do this determines the benefits that they each
get. If the foreign domains that local users wish to send mail as don't
provide SMTP-AUTH, there is a lot of pressure on the local ISP to continue
to allow domain forgery.
In that respect, it is a lot like outgoing port 25 blocking coupled with
rate limiting and outgoing virus scanning at the smarthost. If you are the
only ISP in the world that does it, there is little benefit. When a lot of
ISP's do it, they all benefit. This is precisely the case with SPF. If you
publish a record and nobody checks SPF at incoming, you don't benefit. We
are all betting that eventually, sites will be able to reject on SPF fail
before data.
Recently, I tried to convince my local ISP to turn on SMTP-AUTH services
(part of my discussing SPF with them) in _addition_ to POP before SMTP, and
consider making that the default setup for new customers only. They could
then leave all their existing customers on POP before SMTP and let customer
turnover cut down the size the eventual switchover problem when originating
domain authentication becomes more widespread. They could also offer their
roaming customers a better experience than webmail, which would further cut
down the number of POP before SMTP users. They asked me, completely in
earnest, "You mean you _really_ can't connect to us on port 25 when you're
traveling?". I asked them if they blocked outgoing port 25, and they
answered yes, but they still barely understood the problem. They'll
eventually get it (their port 25 blocking and rate-limiting was a result of
my suggestion to the local manager), but it may take a long time. I suspect
these folks are fairly typical in their attitudes for mid-sized ISP's. They
have about 35K customers locally, but operate in a couple dozen other local
markets about this size, giving them around a million total customers.
--
Seth Goodman
-------
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