Avleen Vig wrote:
>
> On Sun, Mar 21, 2004 at 08:23:09PM -0600, Edgar Lovecraft wrote:
> > I cannot let that slide, even though my opinion has been called nieve.
> > Why use SPF when there is a much simpler approach to those examples.
> > EVERY ISP should at the very least scan email for viruses before the
> > message leaves its relay servers, so how does SPF protect what message
> > scanning does not.
>
> Because virus scanners:
> 1) always lag BEHIND the latest viruses, anythign from hours to days
> 2) virus scanning is *very* expensive both in CPU and financial
> respects
> 3) SPF is significantly cheaper and not only catches the
> virus example but the spam one too
>
Only if the virus/spam says it is being sent from a domain that it should
not be, the scanners pick things up no matter what, so as I said, ALL ISP's
'should' at the very least, scan all outbound email.
Good virus scanners are not that far behind the latest and greatest that
comes out (the occasional new one does however get passed, but almost all
'new' viruses are are reimplementations of old ones and get picked up on
'old' definitions, not 100% but 99% of the time)
>
> > As to 'direct to MX' this is where EVERY ISP should disallow outbound
> > port 25 (SMTP), thus forcing the spam/virus to send either through the
> > relay, or to another relay that is on a port different than 25 (wich
> > can be easily tracked). So again, how does SPF help?
>
> Here I agree 100%. We (the ISP where I work) does this, but it is only
> applicable to those users whose circuits pass directly through the ISP's
> network like dial-up or DSL. Cable broadband and satalite does not and
> it is much harder to block in this way. Actually because multiple ISP's
> can share the same Cable / Sat service, I believe it's near impossible.
>
This is not true, the majority, or all Sat services require you to
'dial-up' for outbound content, they must still dial up somewhere, and at
that somewhere there is a router, any ISP is going to have a router that is
capable of blocking TCP port traffic, the same is true with Cable, DSL,
wireless, and standard dial-up connection. There will always be a 'router'
at the 'connection point' to the rest of the world (internal to an ISP's
network could be different, but that all depends on the ISP and how they
have setup the internal network), as an example, my home ISP is Cox Cable,
I do not have 'a direct connection to the Internet' as some believe, my
Cable modem gets an IP address from a Cox DHCP server, and Cox has routers
that take my traffic to the 'world at large'
example partial trace to www.exim.org from my workstation:
1 17 ms * 13 ms ip68-102-96-1.ks.ok.cox.net [68.102.96.1]
2 18 ms * 15 ms ip68-103-127-1.ks.ok.cox.net [68.103.127.1]
3 20 ms 20 ms * 68.12.13.29
4 25 ms * 22 ms mtc3bbrc02-pos0101.rd.ok.cox.net [68.1.0.108]
5 18 ms * 35 ms mtc3bbrc01-pos0100.rd.ok.cox.net [68.1.0.102]
6 26 ms * 25 ms dllsbbrc02-pos0103.rd.dl.cox.net [68.1.0.107]
7 26 ms 31 ms * unknown.Level3.net [209.246.136.33]
As you can see, there are at least six devices under the direct control of
Cox Communications that could be set to block any port they desire. The
same is true for any connection including 'piggy back' ISP's such as the
AOL braodband type of connections.
>
> > My solution proposed above is easier to implement than SPF, and DOES
> > NOT require 'global compliance' to work, as thse ISP's that do allow
> > 'rouge' traffic are going to be discredited and 'blacklisted' in their
> > entirety until the problems are taken care of.
>
> Before you do that, please figure out how to solve the cable/sat problem
> highlighted above.
>
See above...
>
> > Is this inconvienient to those that do not 'pay for the priviladge' of
> > running thier own servers (either 'business class connections' or 3rd
> > party relay server) yes, but so is SPF, and SPF is less friendly to
> > thses people than my solution (but just with SPF my solution does not
> > 'fix' everything). Cheers!
>
> It's a minor inconvenience but it's about the same as SPF, no better or
> worse. I'll agree that there isn't one final "good" solution.
No there is not, but I personnaly (please notice the I I I :) feel that
SPF can be of use for the information that 'AOL gaurantees?' servers xy & z
ALWAYS send 'good? AOL' messages. That is good information, but to say
that ANY other AOL domain email is false, is just not true. That is why
I do not like the approach or 'selling point' that SPF has used (or now
has) that you should absolutley NOT trust email from other sources, that is
just not true, nor is it true that ISP's should say 'hey, we can fix your
spam problems with SPF!', there again, that is a false and/or misleading
statement.
I really do not think that the technical people that deal with this all of
the time fall for that, but the general public just does not understand
(and of course, that leads to many other things :)
Really, SPF has only picked up speed recently because AOL has stated they
are going to/are currently, useing it. Unfortunatly I believe, AOL is a
much larger 'marketing' source than they are ISP any more, who would
have really cared if Comcast had said they use SPF?? They just do not have
the marketing prowess of an AOL.
AOL does use many other less publicized anti-spam measures that are good,
just for example, not gauranteeing that they will accept email or
connections from MTA servers that have NO rDNS. These are the types of
things that they really should be marketing, not SPF as AOL may/may not
care if they break someone's personal web page. But when they do, what is
thier 'fix' for thier customer?
That is another reason I prefer an approach to what I stated, at least the
ISP's could say hey, you just cannot send on tcp port 25, but...
--
--EAL--
