[Mimedefang] Checking for a valid sender

[Cormack, Ken]

-----Original Message-----
From: Alan Madill [mailto:amadill at hwy16.com]
Sent: Tuesday, November 18, 2003 12:51 PM
To: mimedefang at lists.roaringpenguin.com
Subject: Re: [Mimedefang] Checking for a valid sender

::snip::

> Verify that the sender is real.  (there goes 90% of your spam).

You'd never be able to verify senders from my environment.  Between the
gateway machine in my DMZ, and the Exchange servers that house the users'
mailboxes, there are intermediate sendmail relay hosts, as well, which in
addition to relaying per domain, are also performing both virtusertable and
genericstable email address conversions on the fly.

My appologies if this upsets you, but I have no plans to have LDAP provide
my corporate Global Address Lists from the Exchange servers to any system in
my DMZ.  In the event a DMZ system is compromised, I want as few protocols
as possible available, and little-to-none internal information made
available to a compromised machine.

I agree that either a "new" or "enhanced" protocol is required.  However, in
the meantime, you cant mandate that legitimate hosts on complex networks run
by security-conscious admins be willing to make addresses available for
harvesting by anyone on the outside.  I dont own my company, nor do I own my
customer's companies.  And the share-holders of each will not sacrifice
security for the sake of a few spams.

The first rule of security is to never reveal more than you have to.  Any
security-related sendmail documentation will also tell you to turn off
address verification by sendmail with a directive such as this, in your
sendmail.mc file:

	define(`confPRIVACY_FLAGS', `goaway,restrictmailq,restrictqrun')

Among the things this disables, is the SMTP "VRFY" command.

Yes, there goes "90%" of your spam, you say.  (We're blocking ~97.4% daily,
without doing what you're suggesting, and that's with HTML-mail enabled.)
But I'm willing to bet an equally high percentage of legitimate mail will be
stopped, as well.  There are better ways.  This just isnt one of them.

You're better off doing other tests that stress-test the rfc-compliance of
headers, with LOCAL_RULESETS available on the 'Net.  That alone, blocks
~4300 messages daily, on my gateway.  It's well known that most spam-sending
apps dont pay too much attention to the rfc's.  And non-enforcing systems
that allow receipt of non-conforming sender engines dont help the problem.
You may occasionally find a "real" MTA that is also lax or broken, but you
can then add exceptions for those.

Ken