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
Attachment:
signature.asc
Description: Digital signature