Santronics Software, Inc.,
wcSAP - Wildcat! Sender Authentication Protocol

wcSAP focuses on the "delivery process" making sure the sender of the mail is valid.  The system works well because the majority (atleast 60-80%) of all spam is sent using fake or bad email addresses or sent by machines who have a bad "reputation" for sending spam.

wcSAP offers a way to enforce mail senders to comply with the SMTP standards using a suite of multiple test methods.   Once the recipient of the message (RCPT TO) is known,  wcSAP is called to validate the sender using the following methods in the specified default order:

As of Wildcat! v6.4, the old SAPCEP testing option was obsolete and no longer available in wcSAP.

wcSAP will start with the SAPFILTER test and continue until the first test rejects or accepts the sender. The final test performed is SAPCBV.

The wcSAP configuration file is located in wcSAP\WCSAP.INI and you use a standard text editor such as NOTEPAD to edit this self-commented setup file. You can also use the new web-based wcAVS manager to edit/change wcSAP options by linking to /services/wcavs URL on your Wildcat! Web Site.

Parameters passed to wcSAP:

When wcSAP is called wcSMTP or directly using wcRUN,  the following parameters may be passed:

Field Description
IP Client machine internet IP address, x.x.x.x
CDN Client machine domain name as provided at HELO/EHLO
FROM The sender return path email address as provided at MAIL FROM: 
RCPT The recepient address when wcSAP was called.
STATE The wcSMTP state machine command when wcSAP was called. This is usually RCPT, but it could be MAIL.
RBL This value is 1 is wcSMTP performed a RBL check and the sender was rejected.  This tells wcSAP not to perform any more testing.  You should turn wcSMTP SPAM RBL options when using wcSAP RBL options.
RELAY This value is 1,  if the sender was authenticated or trusted to relay mail.  This tells wcSAP to skip testing since having Relay Access usually means you have established trust with the sender.    
TRCPT Total Recepients entered by the sender when wcSAP was called.
BRCPT Total Bad Recipients entered by the sender when wcSAP was called.
LDN Local domain name of the wcSMTP server.
LIP Local IP address of the wcSMTP server.
HDN rDNS domain name of the client IP address.
DEBUG 0 to 10, sets the log verbosity. Default 0.
XML 1 if, XML output is desired.  Default 0 (off)

The IP, CDN and FROM are the basic three parameters requires to perform a complete wcSAP test.  All the rest are optional and useful if you have SAPFILTER rules in the file wcSAP\WCSAPFILTER.TXT specifically defined to check for these parameters, such as RCPT.

For example, suppose a machine at connected to your wcSMTP server to begin a mail transaction.  The C: lines are the commands sent by the sender and the S: lines are the response sent by wcSMTP.

connection ip:
S: S: Wildcat! ESMTP Server v6.0.451.1 ready
S: 250, Pleased to meet you.
S: 250 <>... Sender validation pending. Continue.

At this point, we have the three pieces of information we need in order to begin a wcSAP test.

IP =

However, wcSMTP is pre-setup, by default, to delay the validation until the intended recipient is known and will send a "Sender Validating Pending" response.  Once the RCPT TO: address is entered by the sender:


wcSMTP will now decide if it needs to call wcSAP.

If the recipient was accepted (known address), wcSAP is called to validate the sender.  If the recipient was unknown, then there is no need to call wcSAP because the mail will not be accepted until the recepient is valid.

When wcSAP is called, the paramaters are passed to it and the testing begins.  When wcSAP returns with a result, wcSMTP finally send a response to the RCPT TO: command:

** WCX Process: wcsap ret: 450 (Rejected by WCSAP CBV)
S: 552 Return Path not verifiable.

For the above example, the sender was rejected due to a wcSAP CBV (callback verification) test.  To see the details of a wcSAP session, the wcSAPyyyymmdd.log file can be viewed.

The following sections describes each test method performed by wcSAP:




When EnableFLTCheck is enabled (TRUE), the filter file defined by FilterList (wcsap\wcsapFilter.txt) is used to read in Accept or Reject rules defined by you.   This is considered your internal white or black list.  It is a fast test thus it is the first test performed by default. 

See the WCSAPFILTER.TXT file for self-contain help on creating Accept/Reject rules.


wcSAP\WCSAP.INI options for SAPRBL:


When EnableRBLCheck is enabled (TRUE), the next test is the Real time Black List (RBL) lookup test.  

wcSMTP currently supports SPAM RBL built-in with only one RBL site available for testing.  We recommend the wcSMTP SPAM RBL option is turned off and allow wcSAP to perform RBL testing. This will reduce overhead on your system since RBL testing may not be required if the sender is rejected with SAPFILTER.   With SAPRBL, you have more options to define multiple RBL sites with the CheckRBLSite keyword.  In addition,  wcSAP uses an advanced "learning" method to reorder the RBL sites by fastest lookup queries.  

Note: SAPRBL is a good method for protecting your system against known spammers.  RBL is a "reputation" testing method.  Since it is possible for spammers to pass the remaining test methods, wcSAP will perform the RBL test (by default) before the remaining test methods are applied.


wcSAP\WCSAP.INI options for SAPSPF:


When EnableSPFCheck is enabled (TRUE), the next test is the SPF (Sender Policy Framework) test.  

SPF will help protect domains spoofed by spammers and SORBIG-generation email viruses who steal legitimate email addresses for illegal bounce messages.  SPF is rapidly becoming a new internet standard where system administrators using DNS TXT records, can define the valid machines on their mail network allowed to send mail .  SPF is documented at

Although SPF may sound complex, it is based on a simple concept asking the fundamental question:

"Does the machine at IP address connected to my server have permission to send mail on behalf of the sender's domain provided at HELO or MAIL FROM?

Using the example above, the question translates to:

"Does the machine at connected to my server have permission to send mail on behalf of the sender's domains or

With SPF enabled, wcSAP will lookup the DNS SPF TXT record for the domain, if any,  and check to see if the domain has established a SPF policy exposing the valid machine addresses allowed to send mail.  

If the IP address is not found in the SPF policy, then wcSAP may reject the transaction depending on the SPF policy when no IP address match is found.

For the example domains, neither have SPF records.  However, for the sake of illustrating how SPF can be used to validate the sender,  if a SPF record was found for the domain, it could have a simple SPF record such as:

v=spf1 ip4: -all

which would validate the sender because it defines an IP address statement (called SPF directive) that matches the connected machine's IP address.  If it did not match, the final -all SPF directive indicates the sender should be rejected.    SPF has support for "relaxed" final results called neutral and softfail:

We believe this is unfortunate as it provides a "loophole" for spammers to continue to use spoofed domains with SPF records who have neutral and softfail results for non-matching IP addresses.    AOL.COM is an example of a "neutral" no ip match result.  SPF says mail "should not" be rejected with neutral results.  wcSAP provides options to control this logic:

Accept-SPF-SoftFail FALSE
Accept-SPF-Neutral FALSE

By setting these options to FALSE, it allows wcSAP to continue testing.

If you want to see if a specific domain has a SPF record defined in DNS, you can use Window's NSLOOKUP.EXE command like so:

nslookup -query=txt

Try it for a domain that has a SPF record, such as

nslookup -query=txt

See the SPF support site on instructions to create your own SPF record in your DNS server.  

SPF Records For Wildcat! Sysops:

It is highly recommended you create SPF records in your DNS server or ISP's DNS server for all of your email domains and also MX host domain names to protect against spoofing domains.

For Wildcat! sysops, the simplest and generalized SPF record for your wcSMTP setup would be:

v=spf1 a mx ptr -all

You would enter this as a DNS TXT Record for each of your email domains wcSMTP is handling including the MX host domains for wcSMTP.    This is an easy process with the Microsoft DNS server manager.  Simply highlight the zone and add a TXT record.  If you are using other DNS server, consult the specific DNS server documentation on adding TXT records for zones.

This SPF record should work for your wcSMTP setup.  However, if you want to speed up SPF processing, you can be specific and put the IP address of the machine where wcSMTP is located:

v=spf1 ip4:x.y.z.w a mx ptr -all

where x.y.z.w is the IP address where wcSMTP is running.  You may have multiple ip4 statements (SPF directives).  

If you have a class C network, and you want to declare that all local network machines are allowed to send mail to wcSMTP, then you may use a IP4 CIDR range format.

v=spf1 ip4:x.y.z.0/24 a mx ptr -all

For other arrangements, see the SPF support site.



wcSAP\WCSAP.INI options for SAPCBV:


When EnableCBVCheck is enabled (TRUE), SAPCBV is the final test performed when all others test are passed by the sender.

CBV stands for "CallBack Verifier."   Veteran Wildcat! BBS sysops are familar with telephone based Caller ID call back verifier products popular in the early BBS modem days which were use to validate users connecting to the BBS via modems.   The typical CBV would perform the following:

  1. Wildcat! answers the caller-id ready modem and records the CID (caller id),
  2. For a new user, get some back information from the new user,
  3. Give the user a secret password,
  4. Hang up the connection,
  5. Call back the user using the record CID,
  6. If the user answered the call, he enters the secret password and is told he can now call again with established credentials.
  7. If no one answers the call, the new user record is discarded.

For the internet email SMTP world, performing CBV is conceptually done using the same idea. 

For SMTP, "Caller ID" would be the MAIL FROM: address also called the sender's Return Path.  

The reason why the industry has a big spam and now email-virus problem is because this return path is fake, bad, spoofed 70-80% of the time and SMTP systems have no current provision to validate this return path.

The wcSAP CBV is based on the fundamental premise SMTP mandates the return path to be a valid address in order to send system notification or bounce mail.  If it has to be valid for bouncing mail, then it needs to be valid when the mail is first sent.   This is the basis for the wcSAP CBV.

SAPCBV will perform an SMTP-based call back to the MAIL FROM: address as if SAPCBV was going to send mail to it. But it doesn't send mail. It does everything a normal mail sender will do except actually send a message. The CBV simply needs to find out of the remote server will accept the return path issued as a RCPT TO: address at the remote server.

So if we use the above example, with a MAIL FROM: address of edwdeswtxekf@334es5s.comSAPCBV perform a 100% compliant SMTP operation of:

and see how the remote mail server to the RCPT TO: command.

If the remote server rejects the RCPT TO: address, then we 100% verified the address is BAD. SAPCBV will gracefully end the remote session and inform WCSMTP to reject the mail transaction.

If the remote server accepts the RCPT TO: address, then SAPCBV performs one more test to see whether this remote server is an honeypot or open relay by testing to see if the remote server will accept any random address.  If the remote server rejects the random address, then SAPCBV has completed its job can no longer make a decision. WCSAP informs wcSMTP to allow the transaction to continue.

On the other hand, if the remote server accepts the random address, then SAPCBV views this as an "open relay" and will inform WCSMTP to reject the sender.   This CBV open relay this is optional. However, it works so we recommend that you don't turn it off.   If you turn it off, you make SAPCBV testing weak.