Re: Rejecting viruses the Right Way[tm]

From: Karsten M. Self (kmself_at_ix.netcom.com)
Date: 02/13/04

  • Next message: Marc Wilson: "Re: a2ps borders problem after upgrade"
    Date: Thu, 12 Feb 2004 22:18:32 -0800
    To: debian-user@lists.debian.org
    
    
    

    on Mon, Feb 09, 2004 at 11:45:15AM -0500, Derrick 'dman' Hudson (dman@dman13.dyndns.org) wrote:
    > On Sun, Feb 08, 2004 at 02:18:07PM +0100, Kjetil Kjernsmo wrote:

    > > If I've understood the configuration I have tried to make correctly,
    > > if you reject the virus in the SMTP-dialog, either due to a unknown
    > > username (in the RCPT TO) or because it has a MS executable (in
    > > DATA), that bounce should not go to the address in the return-path
    > > or MAIL FROM: Which is good, because it is trivially forged, and so,
    > > a bounce that goes to the addresses there will often end up at an
    > > innocent third-party.
    > >
    > > If, OTOH, you first accept the message, _then_ bounce, the bounce
    > > will go to that innocent third party. So, one shouldn't do that. If
    > > the message is accepted, it is too late to bounce.
    >
    > If a message is either rejected (during the SMTP dialog) or bounced
    > (after accepting and queueing the message) then the same innocent
    > third party receives some junk mail.[1] The difference is only in
    > which server is sending the bounce message.

    Not so.

    Few viral SMTP servers will generate and forward a bounce.

    SMTP servers holding an open connection with the originating MUA (or the
    virus itself) will pass the reject message to the originating client.

    Only misconfigured smarthosts will generate a spurious bounce.

    > The best way to handle accurately identified Windows crap is to
    > discard it - accept the message but do not actually deliver it.

    I disagree: you're doing the right thing. Telling the source of the
    virus that it's got a problem. Now, if that source does the _wrong_
    thing with the infomration, _it_ deserves to be LARTed. But that's not
    _your_ fault, and it _is_ encouraging the originating party to Do The
    Right Thing.

    Peace.

    -- 
    Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
     What Part of "Gestalt" don't you understand?
        The truth behind the H-1B IT indentured servant scam:
        http://heather.cs.ucdavis.edu/itaa.real.html
    
    

    -- 
    To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    


  • Next message: Marc Wilson: "Re: a2ps borders problem after upgrade"

    Relevant Pages

    • Re: Rejecting viruses the Right Way[tm]
      ... | that bounce should not go to the address in the return-path or MAIL ... (after accepting and queueing the message) ... generates the bounce and sends it to the innocent third party in this ...
      (Debian-User)
    • Re: Unexplained email sent (not spoofed), apparent Netsky
      ... that you received a 'bounce' email message with a spoofed 'From' email ... Even though I have up-to-> date NAV Auto-protect on, I noticed an outgoing email that> I had not originated, and ran a virus scan plus utilities> from Symantec and McAfee, and even looked in registry and> other places for typical entries/files, all with negative> results. ... > Ironically enough, the outgoing message was _apparently_> to Network Associates, as it bounced with body "Network ... > Since the outgoing mails seem to be really originating> here, not spoofs from some other site, and are going to at> least one unknown address, I am concerned that I am> entertaining a Trojan or back-door server unawares. ...
      (microsoft.public.security.virus)
    • Re: Is it just me that is being picked on?
      ... >does dot accept anything to bounce back; ... >by the MTA that is originating the email, NOT the MTA that is rejecting the ... >accepts no mail beyong sufficient identification to determine the rejection. ...
      (comp.os.linux.misc)