On the value of virus notifications [LWN.net]

On the value of virus notifications

Posted Aug 21, 2003 6:37 UTC (Thu) by zmi (subscriber, #4829)
Parent article: On the value of virus notifications

The REAL problem is that it is still possible for any virus/worm/software to actually
forge the sender. The mail software (MUA/MTA) should include prevention against
this (e.g. users sending over @mydomain.isp should only be able to send as
<userpart>@mydomain.isp, and not as anybody else). If the mail software would
stick to that, at least all replies only go to the mail server they came from - and
suddenly that administrator will be *forced* to do something in order not to be
overflooded.

You need "your mail was filtered" messages because it could be that because of a
false positive a correct e-mail was filtered, and then you should know that it was
thrown into /dev/null.

(Log in to post comments)

On the value of virus notifications

Posted Aug 21, 2003 7:12 UTC (Thu) by proski (subscriber, #104) [Link]

The REAL problem is that it is still possible for any virus/worm/software to actually forge the sender.

Agreed. But it's not like "the real problem" going to be fixed soon. There is one realistic proposal though, it's called Reverse MX.

You need "your mail was filtered" messages because it could be that because of a false positive a correct e-mail was filtered, and then you should know that it was thrown into /dev/null.

I disagree. In case of viruses, the only "false positive" would be a delibrate attempt to infect the recipient, provided, of course, that the virus signature is long enough and is matched exactly.

On the value of virus notifications

Posted Aug 21, 2003 8:26 UTC (Thu) by dlang (subscriber, #313) [Link]

however even virus definitions are not that good. it's relativly common for files to match up with virus definitions.

you still have the false-positive problem

Spotting forged email with MTAs

Posted Aug 21, 2003 13:06 UTC (Thu) by dps (subscriber, #5725) [Link]

> The REAL problem is that it is still possible for any virus/worm/software
> to actually forge the sender. The mail software (MUA/MTA) should include
> prevention against this (e.g. users sending over @mydomain.isp should only
> be able to send as <userpart>@mydomain.isp, and not as anybody else).

Implementing this is not really feasible unless you have seperate mail servers for mail coming in and going out, which is very rare. I know of perhaps one very large ISP with such a system... so filtering MAIL FROM: to insist on something local is not possible.

It might just be possible if you check the source IP in your check_mail ruleset but doubt it is worth the agro generated when the first few iterations are <100% correct. Until a reliable "cookbook" version of this is avialable I doubt many people will implement this.

You can, and I have, impelement a rule that stops the mail if neither the sender nor the recipient is local. My version of this is based on sendmail's check_compat ruleset and this is not the only anti-relaying measure on the internal mail server (which the poublic can not reach). This stops the vast majority of forged email.

There are cookbooks and hints to help clueless sysadmins insist on one local address (which are also useful for clueful ones too :-) IMHO someone else to take the mistakes before you is always useful for anything as hairy as sendmail rulesets.