lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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