WCSAP
Wildcat! Sender Authorization Protocol
(c) copyright 2003-2004 Santronics Software,Inc.

(in construction)

Santronics Software, Inc (SSI),  with its continued efforts to combat electronic mail abuse also known as "spam," now offers a suite of advancded anti-spam technologies and/or methods called WCSAP,  Wildcat! Sender Authorization Protocol.

How it works:

The following are the  typical SMTP mail flows from a MUA (Mail User Agent) mail sender to a final destination MDA (Mail Delivery Agent):

MUA1 (sender)

= P2:Host Direct =>
= P3: Host Route =>

 MTA1 (wcSMTP)
Originating Mail Receiver

= P2: Final Destination=>

 MUA1
Recipient
|
P1: Direct
|		 |
P3:  Route
|
MDA3
Final Destination		 MTA2 (router)
| |
MUA3
Recipient		 MDA2
Final Destination

There are basically three mail paths:

  1. Client Direct:  Anonymous MUA to recipient at final destination MDA,
  2. Host Direct:  Anonymous MUA to MTA1 to recipient at final destination MDA1,   and
  3. Host Route: Authenticated MUA to MTA1 to MTA2 router to recipient at final destination MDA.

What is important to understand about the email system and how wcSMTP is designed, is that final destination transactions do not required authentication.  The connecting client need only anonymous access.    Authentication is only required when a route is required such as path #3.

Typical Flow

Figure 1.0 illustrates the basic SMTP protocol state machine.  When a mail client attempts to send mail to your system, it connects to your and mail server and then issues five SMTP commands starting with HELO (or EHLO) to start and complete a transaction. 

In wcSMTP,  validation is done at each state from HELO/EHLO to DATA.  A client can not reach the next state unless it passes the current state.   

 

WCSAP is designed to validate each state upto the DATA state.   If a client passes all the checks WCSAP performs,  then the DATA is transfer.    If you are using the SMTPFILTER or wsMailGuard system, then  the DATA is validated with these tools.  

smtpstatemachine.jpg (25359 bytes)

 

  1. Check a blacklist to indicate return path rejection,
  2. Check a whitelist to indicate return path acceptace,
  3. Verify the return path.

In step 3, the verification process consist of the following:

  1. Reject, if the connection to the remote MTA fails,
  2. Reject, if the remote MTA provides a negative welcome response,
  3. Reject, if the remote MTA does not allow a NULL return path,
  4. Reject, if the remote MTA does not recognize the senders return path.

Otherwise, WCSAP will turn a positive result and the WCSMTP mail server will continue with the next step in the mail session

Technical Features:

To comply with RFC 1123,  WCSAP offers flexible response codes to be in used in the MAIL FROM: response to the remote MTA.  For example:

WCSAP offers RBL support, however, the WCSMTP server will have performed RBL operations at the connection level and pass the RBL results to WCSAP allowing it determine if it should continue with return path validation.

WCSAP also help address local domain spoofing, where by a remote MTA uses a final destination domain for the return path.