full-disclosure - Backdoor not recognized by Kaspersky

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200403041702.i24H2h4i015106@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Backdoor not recognized by Kaspersky 

On Fri, 05 Mar 2004 02:27:05 +1300, Nick FitzGerald <nick@...us-l.demon.co.uk>  said:

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

Amen to that.  RFC2821 says:

6.1 Reliable Delivery and Replies by Email

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.

Yes.  Losing the mail in a system crash is a "frivolous" reason.  Harsh. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040304/cc437f03/attachment.bin