bugtraq - Re: RFC: content-filter and AV notifications (Was: Re: RFC: virus handling)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20040203160732.GF26252@wsr.ac.at>
Date: Tue, 3 Feb 2004 17:07:32 +0100
From: "Peter J. Holzer" <hjp@....ac.at>
To: Thomas Zehetbauer <bugtraq@...urityfocus.com>
Subject: Re: RFC: content-filter and AV notifications (Was: Re: RFC: virus handling)

On 2004-01-29 15:00:03 +0300, Andrey G. Sergeev (AKA Andris) wrote:
> Wed Jan 28 2004 18:45:39 Thomas Zehetbauer <thomasz@...tmaster.org> wrote:
> 
> TZ> 2.1.) Avoid
> TZ> Virus filters should
>                   ^^^^^^
>                   MUST
> TZ> therefore be designed and implemented before checking the
> TZ> legitimacy of the intended recipient. This would also avoid
> TZ> helping the virus spread by bouncing it to a previously unaffected
> TZ> third party.

This is a not a good idea. In SMTP, the recipient(s) are transmitted
before the content of the mail. Each RCPT command (specifying one
recipient) can succeed or fail. Checking the legitimacy of recipients
should happen at this stage: Firstly, if no valid recipients are found,
the message doesn't even have to be transmitted. Secondly, at this stage
you can reject the mail for some recipients, but not for others. At the
DATA stage you can only summarily accept or reject it. Thirdly, if you
accept the mail, you have taken over responsibility for it. If you later
decide you cannot deliver the mail, you must generate a DSN. But at that
point you cannot know whether the return path is valid, so you may send
DSNs to innocent third parties. 

If at all possible avoid accepting a mail that you are not sure you will
deliver! Try to do all checks during the SMTP conversion so that you can
reject the mail instead of bouncing it (which will often avoid the
bounce completely, since the SMTP engines used by spammers and worms
don't generate bounces), and do it as early as possible to keep traffic
down.

	hp

-- 
   _  | Peter J. Holzer      | Shooting the users in the foot is bad. 
|_|_) | Sysadmin WSR / LUGA  | Giving them a gun isn't.
| |   | hjp@....ac.at        |	-- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128

Content of type "application/pgp-signature" skipped