on Mon, Feb 09, 2004 at 11:45:15AM -0500, Derrick 'dman' Hudson ([EMAIL PROTECTED]) 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 <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
