Postfix anti-antivirus (was Re: [linux-elitists] procmail recipe for mydoom?)

Martin Pool mbp@samba.org
Tue Feb 10 16:42:51 PST 2004


On 11 Feb 2004, Ben Finney <ben@benfinney.id.au> wrote:
> On 11-Feb-2004, Martin Pool wrote:
> > On 11 Feb 2004, Ben Finney <ben@benfinney.id.au> wrote:
> > > The destination has already reacted exactly the way the relay MTA
> > > should have: by rejecting the message at SMTP time.  The work is not
> > > being shifted by the destination, but *by the relay*.
> > 
> > The relay is too stupid, but the destination ought to know better.
> > The destination knows that if it rejects the message at SMTP time, it
> > will generate junk to the forged address.  It shouldn't do it.
> 
> The destination is acting in the only way that will reliably give
> information to someone who can do something about the problem: the SMTP
> client (relay or otherwise) currently attempting to pass on the malware.

This is the nub of the question.  *If* that information got through to
someone who acted on it, it would be worthwhile.  But I think that
happens rarely or never.

I am curious if you've ever heard of a case where just giving SMTP
rejects caused the client to fix the problem?  I have hundreds of
cases where it caused a false bounce message to be generated.

> As opposed to silently dropping the malware, which isn't acting.

As I say, it avoids causing further damage.  

Sorting the mail into a mailbox or stripping the attachments does not
prevent you sending mail to the client postmaster to complain.  That
is a far more useful action than an SMTP reject.

-- 
Martin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20040211/e0c6dc8c/attachment.pgp 


More information about the linux-elitists mailing list