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 customers 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 mght be encrypted on the ISP's servers, but is almost certainly stored in plain on 
the users PC. If that is correct, why is there so much noise about encryption of passowrds 
and/or data? Why bother to consider it?
Any hacker worth his name is going to be able to pick a victim on the ISP's network and 
spam to his hearts content - as we see all the time. The same could be said for zombie 
connected to the network. It's just too easy.
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.
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 exrta bit of work.
I joined the SPF project because I was under the impression that there was a definite 
movement to tighten up e-mail usage. Unfortunately this seems to not be the case, and 
attitudes of most USA ISP's about SMTP appear to be a bit casual - I haven't checked other 
countries yet - USA generates more than 50% of the worlds spam, so that's a good starting 
place. Given the fact that some USA ISP's have published SPF records, and the casual way 
they authenticate their SMTP sessions, 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

It would be a very interesting exercise to read what %age of those SPF'd SPAM mails are 
using an SPF record of an ISP.
Disenchanted,
JohnP

-------
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