[Esd-l] Bounces go to wrong people

[John D. Hardin]

On Sun, 29 Dec 2002, Victor wrote:

> Hi. I am faced with this issue: a spam message comes in with a .bat 
> attachment, but the Reply-To: header is set to some legit user on yahoo. 
> So they get tons of "SECURITY WARNING" messages even though they sent 
> nothing. Any of you guys faced this situation? Any clues as to what I 
> can do here? I know that From: can be forged too, but stopping this 
> notice from going out at all gives no notice to those who just 
> accidently send unallowed extensions and then wonder why their mail 
> didn't arrive...

Everyone faces this. Worms using forged headers are a fact of life
now.

The current email standards provide no mechanism for reliable
identification of the sender. Where "reliable" sender ID exists it is
implemented on a by-ISP basis - for example, mail sent through AOL
MTAs attempts to identify the originating account by doing something
like looking up the originating IP address in the AOL dialup IP pool
to see which account is logged in. This sort of ID - server-based - is
tough for a spammer or worm to forge.

The sanitizer does what it can to reduce false notices. It's aware of
the AOL sender ID header and uses it if present. It also checks the
envelope sender address (Return-Path:) and compares that to the list
of MTAs in the Received: headers (which are harder to forge) to see if
something blatantly bogus is there (e.g. the message claims to be from
a Yahoo user but didn't touch any Yahoo mail servers at all).

There is no real solution to the problem at this time. Solving the
problem will require an extension or redesign of the email protocols
to provide for reliable identification of the actual sender, and then
adoption of the new standard by ISPs.

I can't see this happening in less than five years. Does anybody here
know if anybody is working on a standard for reliable mail sender ID?

As a practical matter, if you are regularly communicating with a known
set of domains (e.g. your client list), you could "whitelist"
notifications. Turn them off globally, then if the message originates
from a known domain, turn them back on.

   SECURITY_NOTIFY_SENDER=

   :0
   * ^(From|Reply-To|Sender|Return-Path): .*@(dom1\.com|dom2\.com|...)
   {
      SECURITY_NOTIFY_SENDER=Y
   }


You can also put in place the local-filters list, with notification
for recognized worms turned off. This will reduce the bogus
notification volume.

--
 John Hardin KA7OHZ    ICQ#15735746    http://www.impsec.org/~jhardin/
 jhardin at impsec.org                        pgpk -a jhardin at impsec.org
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  Outraged over the behavior of the Supreme Court in the 2000 election?
  Get out and vote! They can fix a close race, but they can't fix
  a landslide.
-----------------------------------------------------------------------
   674 days until the Presidential Election