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.

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 67.99.47.221 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: 67.99.47.221
S: S: 220-winserver.com Wildcat! ESMTP Server v6.0.451.1 ready
C: HELO mail.sjoiim.org.mx
S: 250 winserver.com, Pleased to meet you.
C: MAIL FROM:<edwdeswtxekf@334es5s.com> SIZE=782
S: 250 <edwdeswtxekf@334es5s.com>... Sender validation pending. Continue.

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

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:

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.

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.

EnableRBLCheck
SkipRblRejects
LogRblRejects
CheckRBLSite
SlowRBLSiteLimit
RblRejectCodes

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.

EnableSPFCheck
SPFTestDomain
Accept-SPF-Pass
Accept-SPF-SoftFail
Accept-SPF-Neutral
EnableReceivedSPF

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 http://spf.pobox.com.

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

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 334es5s.com, it could have a simple SPF record such as:

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:

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:

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

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:

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:

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.

EnableCBVCheck
SkipRblRejects
SkipPostMaster
NoDomainReject
NoMXReject
NoMxTryDomain
SocketWaitTime
UseNoop
UseEhlo
UseVRFY
SapHost
SapMailFrom
UseRSET
OpenRelayCheck
RejectOpenRelay
OpenRelayAddress
rescode_nodomain
rescode_nomx
rescode_connect
rescode_welcome
rescode_helo
rescode_from
rescode_rcpt
rescode_rcpt_fail
rescode_relay
UseIPCResponse
UseMXMultiHost
MaximumMXHost

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:

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.com, SAPCBV perform a 100% compliant SMTP operation of:

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.