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 system that will 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:
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. You can use a standard text editor such as NOTEPAD to edit this self-commented setup file. Parameters passed to wcSAP: When wcSAP is called wcSMTP or directly using wcRUN, the following parameters may be passed:
The IP, CDN and FROM are the basic three parameters requires to perform a complete wcSAP test. All the rest are optional. 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 IP = 67.99.47.221 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: C: RCPT TO:<support@santronics.com> 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) 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: wcSAP\WCSAP.INI options for SAPFILTER: EnableFLTCheck 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: EnableRBLCheck 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 by far the #1 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: EnableSPFCheck 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:
Using the example above, the question translates to:
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:
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:
Try it for a domain that has a SPF record, such as winserver.com:
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:
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.
For other arrangements, see the SPF support site. wcSAP\WCSAP.INI options for SAPCEP: EnableCEPCheck When EnableCEPCheck is enabled (TRUE), the next test is the CEP or Microsoft' CallerID Email Policy test. CEP is relatively new and it is nearly equivalent in logic to SPF. CEP does not have the large support yet as SPF. However, it should go without saying Microsoft CEP will become a major new internet standard in short time once it is added to their software packages. The main differences between SPF and CEP are:
You have the option to use SPF or CEP or both. As with SPF, system administrators using DNS TXT records, define the valid machines on their mail network who are allowed to send mail for each _ep.domain. Microsoft's CEP is documented at http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx Microsoft CEP Records For Wildcat! Sysops: For Wildcat! sysops, the simplest and generalized CEP record for your wcSMTP setup would be:
Where X.Y.Z.W is the IP address of where wcSMTP is running. You would enter this XML record as a DNS TXT Record for each of your email domains wcSMTP is handling including the MX host domains with one slight difference; the TXT record is added for the "_ep." sub-domain. This is an easy process with the Microsoft DNS server manager. If you are using other DNS server, please consult the DNS server documentation on adding TXT records for sub-domain/zones. For other arrangements, see the Microsoft CEP support site.
wcSAP\WCSAP.INI options for SAPCBV: EnableCBVCheck 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:
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.
|
||||||||||||||||||||||||||||||||