Message-ID: <4047E579.14507.5CB85A4@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Backdoor not recognized by Kaspersky

"Larry Seltzer" <larry@...ryseltzer.com> to 'Mike Barushok':

> >>SMTP auth does not help at all. A virus that delivers email via it's
> own SMTP engine completely bypasses the end users ISP server(s). And if
> the recipient server does not allow incoming mail from wherever it is
> presented from, then incoming mail will simply be broken unless there
> is some sort of SPF. 
> 
> Yeah, exactly, that's the point. SMTP AUTH plus something like
> SPF/CID/DK would stop all the existing worms from operating.  ...

Larry -- I don't give a flying f*ck about the current worms.  Most of 
them have a rather limited life already.  The future worms are the ones 
that interest me because SPF, etc has been promoted through utter BS as 
"preventing" mass-mailing viruses (among other things that it does not 
do).  SPF, etc won't prevent future mass-mailers for the reasons I, and 
several others, have already explained in this thread.

> ...  Mail sent
> through their own engines would be rejected by SPF/CID/DK. 

And that's the "problem" -- mail sent through your MUA's "own engine" 
can get through SPF just fine (so long as you accept a whole raft of 
stupid, pointless and unnecessary to the stated purpose as they will 
only hinder law-abiding Email users anyway, restrictions).  What makes 
you think that the next generation of viruses won't be written to work 
like (or even go back to using) your MUA?

And as for SMTP AUTH -- programmed identity theft will deal with that 
just as key loggers and other data stealers work now.

> >>But, SPF, caller-ID, and Domain keys all have major unsolved issues
> with forwards, aliases, corporate employees checking their work mail
> and needing to reply through their home connection ISP, but with their
> company 'From: ' address and several other common scenarios. Until
> their is universal adoption of some add on to SMTP, nobody can reject
> all non-conforming mail safely. 
> 
> It's not hard to imagine the largest ISPs and large corps accepting
> it, at which point it would become necessary for others to accept it or
> risk having their mail shut out. 

So, because Hotmail (say) prefers a particular form of "sender 
authetication" and Hotmail has no concern for the vagaries of others', 
RFC-compliant use of the longest running of the highly useful Internet 
protocols, all those others should be inconvenienced because of 
Hotmail's size and clout in the market?

It will be a sad day for "the Internet" if that is what happens...

> >>All implementations create a much greater load on DNS. 
> 
> Greater, yes. Much greater, I'm not so sure. Verisign doesn't think
> it's a substantial extra load. The DNS data could very reasonably be
> cached. 

Don't know, don't care...

> >>The real issue is that their is no possible algorithmic solution to
> rejecting email reliably based on any of its source, its content, or
> any combination. 
> 
> So SPF/CID/DK don't work? They reject based on domain

See above.  You seem to have this weird idea that because today's spam 
and mass-mailers forge sender information tomorrow's spam and mass-
mailers _must_ continue to do so.  This shows such a grievous lack of 
the most basic of pertinent historical knowledge it would be laughable 
were the consequences and wasted effort for no benefit not so great, 
should folk suffering from your level of misunderstanding prevail.

> >>If the mail is not accepted, laws prohibit silently discarding it. 
> 
> I've never heard this before. What law?

Yes -- that is an overstatement.  However, the RFCs/STDs covering SMTP 
take a pretty sharp stand on what an implementation should and must do 
if it "accepts" a message and then cannot deliver it to (any of the) 
addressees...


Regards,

Nick FitzGerald

Powered by blists - more mailing lists