New user trying to understand mailscanner capabilities to des ign solution

[Trever Furnish]

You didn't mention whether you're using the sanitizer recipe as part of
local delivery or as part of relay delivery.  Usually procmail is only used
for local delivery, but it is possible to configure sendmail to allow
procmail to filter mail that you're not delivering locally.

By "local delivery", I'm refering to the case when procmail is the agent
called to actually write the message to the final mail store, as would be
the case, for example, on a stock redhat system with pop or imap accounts.

If you're using the sanitizer for local delivery only, then there's really
no reason you can't continue to do so - MailScanner does not come into play
at the local delivery level.

If you're using the sanitizer for relay delivery, then you'd (probably) want
to replace it with MailScanner, although I'm not familiar with it enough to
say whether it's easy to run them both in parallel that way.

The way MailScanner fits into the equation is that you run split the message
acceptance and message delivery functionality of sendmail into two separate
sendmail processes.  When a message comes in, the sendmail listener just
drops the message into a queue.  MailScanner watches this queue, scans
messages, and drops (possibly modified versions of) them into another queue.
This second queue is watched by a sendmail queue runner process, which takes
care of delivering the messages.  If the messages are bound for local
addresses, then the sendmail queue runner calls your local delivery agent
(ie procmail).

> -----Original Message-----
> From: Smart,Dan [mailto:SmartD at VMCMAIL.COM]
> Sent: Friday, July 02, 2004 1:57 PM
> To: MAILSCANNER at JISCMAIL.AC.UK
> Subject: New user trying to understand mailscanner capabilities to
> design solution
>
>
> Hi
> I'm a new subscriber looking at Mailscanner.  I have been doing mail
> relaying with spam and virus filtering for years using (under RH7.3):
>
> 1. Postfix
> 2. Procmail
>    a. Niko Kantarakias' "YAVR" procmail virus filter
>    b. John Hardin's "Sanitizer" procmail recipe.
>       (message cleaner, attachment blocker, zip checker)
>    c. SpamAssassin via spamd/spamc
>         1.   Distributed Checksum Clearinghouse (DCC)
>         2.  SURBL lists
>       3. SARE rule sets
>    d. Custom procmail recipes:
>       1. Log mail into MBOX files for monitoring and reporting
>         2. Capture messages to feed Bayes SA-Learn
>         3. Bypass rules for certain senders and recipients.
>       4. Trap stuff for various purposes.
>
> My goal is to replace the procmail process with a unified
> product, but keep
> the capabilities this gives me.
>
> My motivation is getting strong replacement for YAVR -
> Probably ClamAV. YAVR
> has lost its developer/maintainer.
>
> My information need is in deciding whether to use MailScanner
> to replace the
> functionality of John Hardin's Sanitizer (which is very much
> like Bjarni's
> Anomy Sanitizer) or to use Sanitizer *with* MailScanner if it does not
> duplicate it's functionality. And to understand the
> flexibility of reporting
> in MailScanner.
>
> =========================================================
> Here's the functionality in John Hardin's Sanitizer:
>
> HEADERS
> 1. Sanitize bare CR in message headers (Outlook bug). That's also in
> violation of RFC822 so it's a protocol sanitizing issue.
> 2. Sanitize multiple null addresses (sendmail exploit).
>
> ^((resent-)?(sender|from|(reply-)?to|cc|bcc)|(errors|dispositi
> on-notificatio
> n|apparently)-to|Return-Path): *<>.*<>.*<>.*<>.*<>.*<>.*
> 3. Detect and truncate Subject: headers longer then 250 characters, to
> protect Outlook Express users.
> 4. Truncate excessively long (>500) standard headers, to
> address the MS
> Outlook header buffer-overflow bug and to proactively protect
> against other
> BO bugs in other mailers;
> (Mime-Version|(Resent-)?(Date|Sender|From|Reply-To)|(errors|di
> sposition-noti
> fication|apparently)-to|Message-ID|Return-Path|Status|X-Status
> |X-Keywords):
>
> FIX MIME
> 1. Length-limit MIME boundary strings, to proactively defend
> against BO
> bugs.
> 2. Check for a null MIME boundary string and supply one if
> necessary; this
> is a major DoS attack against Microsoft Exchange
> 3. Sanitize MIME values that have been explicitly set to null (e.g.
> encoding="") - this is a major DoS attack against Microsoft Exchange.
> 4. Sanitize double backquotes in MIME headers to prevent
> remote attacks
> against Metamail via the UW Pine MUA
>
> ATTACHMENT HEADERS
> 1. Sanitize files with Microsoft Class-ID extensions.
> 2. Shorten long file names to less than 120 characters
>     a. Collapse runs of spaces in filenames before length-limiting.
> 3. Truncate long attachment headers (vs. RFC822 message headers as you
> noted), again to proactively defend against BO bugs in mailers.
> 4. Fix missing closed quote on filename
> 5. Fix unquoted filenames
>     a. Properly enquote unquoted attachment filenames that
> have embedded
> semicolons.
> 6. Fix trailing periods and spaces in filename.
> 7. Catch encoded periods in filenames and fix encoded plain
> characters in
> filename.
>   Both because there's no reason to encode those characters
> other than an
> attempt to bypass filtering.
> 8. Catch quotes-in-extension attack. Outlook/Windows ignores them. (!)
> 9. Remove embedded RFC822 comments
> 10. Fix attachment headers of the form 'text from file
> "xxxx"' where Outlook
> helpfully looks if the filename can't be determined from the
> headers that
> *should* have the filename.
>
> URLs
> 1. Fix URL Spoofing; a.com%01 at b.com
> 2. Fix URL Obfuscation; a.com at b.com
> There's no good reason to encode plain characters other than
> an attempt to
> bypass filtering.
>
> WEBBUGS
> 1. Sanitize <IMG> tags
> 2. Sanitize webbug images in tables.
> 3. Sanitize the <BGSOUND> tag for webbugs 4. Santize
> "BACKGROUND" subtag for
> webbugs
>
> TAGS
> 1. Sanitize the <LINK> tag.
> 2. Sanitize the <LAYER> tag; this is primarily of interest to
> people running
> webmail programs.
> 3. Sanitize  <STYLE> tags and clauses because they can be used to hide
> scripting code.
> 4. Detect obscured HTML tags.
>         a. Deal with attempted obscuration of tag options
> with &# and %
> escapes.
> 5. Sanitize FORM tags (see bugtraq posting
> http://www.securityfocus.com/archive/1/359139).
>
> ACTIVE SCRIPT
> 1. Sanitize active HTML <DEFANGED_SCRIPT> tags
>         Defang OnCommands such as OnLoad and other OnCommands.
>         Defang script or mocha:
> (["\047\075]|url\()([a-z]+script|mocha):
>         Defang &{:              (["\047\075])&{
>
> ATTACHMENTS
> 1. Strip dangerous attachments based on Extension
> 2. Check zip file for dangerous attachments
>         a. Handles password protected zip files
>         b. Handles obfuscated file names in zip
> 3. Check magic bits to ensure file is what it claims to be.
> 4. Correctly identifies obfuscated file names.
>
> ==============================================================
> ==============
> ======================================
>
> I also need to have robust logging, so I might need to keep
> procmail.  Does
> MailScanner has flexible logging capability?
>
> TIA
>
> <<Dan>>
>
> Dan Smart
> Enterprise Security Specialist
> Vulcan Materials Company
> Birmingham, AL  USA <<Dan>>
>
> -------------------------- MailScanner list ----------------------
> To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
> Before posting, please see the Most Asked Questions at
> http://www.mailscanner.biz/maq/     and the archives at
> http://www.jiscmail.ac.uk/lists/mailscanner.html
>

-------------------------- MailScanner list ----------------------
To leave, send    leave mailscanner    to jiscmail at jiscmail.ac.uk
Before posting, please see the Most Asked Questions at
http://www.mailscanner.biz/maq/     and the archives at
http://www.jiscmail.ac.uk/lists/mailscanner.html