Comment Number: 516761-100002
Received: 6/24/2005 6:12:43 AM
Organization: Santronics Software, Inc.
Commenter: Hector Santos
State: FL
Agency: Federal Trade Commission
Rule: Email Authentication Questionnaire
Docket ID: To Be Added
No Attachments

Comments:

Answers to Specific Questions


1-Santronics has implemented and/or tested following proposed standards for the last two years on over 3000 systems: LMAP (Lightweight Mail Authentication Protocol) based proposals: - DMP (Designated Mailers Protocol) - SPF (Sender Policy Framework) - CEP (Microsoft's Caller-ID for Email Policy) SMTP based Protocols: - DNSRBL (DNS Relay Black List) - CBV (Call Back Verification) - SUBMITTER (currently still under internal testing only) Others explored but rejected or put to the side for various reasons indicated in this RFC (Request for Comment) document. - SENDERID/PRA

2-When Santronics first decided to address the email security problem back in early 2003, it was due to the world wide SORBIG attack that finally opened up the eyes of SMTP developers that something had to be done to protect the SMTP mail transaction process. SORBIG exploited the fundamental "loopholes" or "flaws" in the SMTP protocol namely: - Not Authentication Requirement for Final Destination Mail or Anonymous Final Destination (AFD) transaction. - Lack of Verification of the SMTP process variables (Client Domain Name, Sender Return Path) For backward compatibility concerns, we concentrated on a SMTP based method to validate the process variables. Our first method implemented was CBV (CallBack Verification). CBV is based on the fundamental SMTP concept that the Sender Return Path (issued during the MAIL FROM: state) must be valid (per RFC 2821 specifications) for potential system notification purposes (bounces). So when the MAIL FROM: address is issued by a client, the CBV performs a quick call back to the sender address domain host to validate the address. To our surprise, we found over 94% of all transactions tested under CBV were rejected do to either: - invalid sender address (no remote mail host) - unknown sender address at the remote mail host. This coincided with the industry empirical estimates that over 60-80% of all all sender email addresses are non-compliant with RFC 2821 return path standards (i.e., bad or spoofed address). However, as well the CBV was working in rejecting bad transactions from a SMTP compliancy standpoint with little to no false positives, we realized there would be overhead issues with a SMTP based callback to the remote host on each transaction. So we continued the research for new methods. This is where the LMAP methods were introduced by the IETF ASRG working group. LMAP asked the fundamental question: "Does this client machine have permission to send mail on behalf email domain?" Thus introducing a new SMTP based assertion of: LMAP = IP::DOMAIN where the DOMAIN IP association was defined as a published DNS TXT record. LMAP is just a model, not a specific protocol. Early proposals such DMP and RMX were introduced that were based on this LMAP concept. DMP was easy to explore since it used a TEXT based DNS record. RMX was much other to implement as a binary DNS record. DMP implemented LMAP for the two domains in the SMTP transaction: result = IP :: EMAIL DOMAIN result = IP :: MACHINE DOMAIN In other words, DMP checked the MAIL FROM email domain for authorization and if this fail, then a checked was done on the HELO machine domain. This dual checking addressed the possible forwarding or alias email address problem where the IP::EMAIL DOMAIN association may not be valid but the transaction is legitimate (e.g., ISP user using alias addresses on authorized ISP sites). The major concern of DMP was that it required a TXT record for each email domain and machine domain to cover the spectrum of all authorized sender machines. If the host was large, DMP would place an overhead burden on DNS administrators. In addition, since DMP had a dual lookup concept, there was a high potential for DNS lookup overhead. Although not explored, RMX addressed the issued of having many DNS records to cover a spectrum of network machines. SPF emerged as a blend of DMP eased of TXT usage and RMX's single record syntax to defined a large spectrum of machines. SPF was quickly implemented and we immediately found a flaw in its initial specification which is to only perform an email domain check and only a machine domain check when the email domain was NULL (bounce message). if email address is NULL check machine domain otherwise check email domain With DMP, it was able to trap spoofed machine domains (which presented at 12% of our transactions). With SPF, it provided a loophole for spammers with avoid machine domain spoof checking. We were able to successful convince the SPF authors to add a provision similar to DMP. With five methods in place RBL, DMP, SPF, MSCEP and CBV implemented (altogether called WCSAP, Wildcat Sender Authentication Protocol) , on November 2003, we went into beta testing on over 150 field test sites. The results were overwhelming with over 90% of all bad transactions rejected based on one of the four methods tested in sequence with the CBV being the final check. However, what was immediate apparent was the higher overhead in DNS lookup based on the open-ended lookup of machine and email domains. The average transaction time was about 65 seconds. So our next emphasis was to reduce this overhead. One interested fact about all transactions was that 65% of all transactions which made it to the RCPT TO (Recipient Address) state in SMTP were bad addresses (user did not exist). So we implemented a delay verification concept to only check WCSAP when the recipient address was valid. This reduced the WCSAP overhead by 60-65% and reduced our average transaction time to 20-25 msecs. For a complete 2 year accumulation of WCSAP statistics see: http://www.winserver.com/spamstats In summary: In our view, no system should be perform high overhead checks if the transaction will not be accepted in the first place because the user does not exist. This is why we are strongly against any protocol that emphasizes payload reception to perform email authentication and deemphasizes SMTP transaction level checking that will reduce the payload overhead. SenderID/PRA is a protocol which is very problematic because it ignores SMTP level parameters and requests the payload before checking is done. Our R&D has proved that SenderID/PRA - For 80-88% of all transactions, the SenderID PRA address extracted from the 2822 payload is equal to the 2821 MAIL FROM SMTP level address. - The PRA algorithm is flawed with no logical reasoning for its extraction logic. - SenderID/PRA is incompatible with legacy systems because it requires 2822 headers in the transactions which are not technically required to be present in the payload. In such situations, the typical SMTP server will add the headers, specifically Date: Message-ID: and From:, and To: based on the 2821 Mail From and 2821 RCPT TO addresses respectively.

3-Our WCSAP suite of protocols as described in detail in response #2, are implemented and perform in the following top/down order: FILTER - Rule based white/black list RBL - Reputation DMP - LMAP method, now deprecated CEP - LMAP method, scheduled to be deprecated SPF - LMAP method CBV - Call Back Verifier The above order is optional and definable by system administrators, but it is the default order perform. Over 3000 systems are using our wcSAP with high success with little to none, false positives. FILTER checking is done first for fast white/black listing. If pass, the next check is done. Using our MAY 2005 statistics, is represents 4.2% rejection. RBL checking performs an IP address reputation lookup on 3rd party DNS zone databases holding collections of reported spammers or open relay sites. If pass, the check is done. Using our MAY 2005 statistics, is represents 61.2% rejection. DMP has been deprecated since no one uses DMP DNS TXT records in any significant number. So it is turned off by default. CEP is a clone of SPF but instead of using a linear text syntax for the DNS SPF records, CEP uses a XML text format instead. Since CEP DNS records was only defined Microsoft domains (i.e., HOTMAIL.COM) and HOTMAIL.COM is high abused domain, we kept CEP support using a simple CEP to SPF converter to perform the SPF check. The rejection rate is negligible. SPF checking using the original SPF specification where the machine domain is only checked when the sender email domain is null. By the time the debates over this issue was over and the current SPF1 was written to include optional machine domain checking, we found that it was better to perform a lower overhead IP:DOMAIN check for local domains only (domains you own). In other words, if a transaction attempts to spoof the machine domain with the idea to fool a system thinking it is local machine, our FILTER rules will perform a non-DNS domain vs IP checks we call DIP (DOMAIN::IP) rules. For example, for our company domain santronics.com running on the 208.247.131.9 machine, no other machine can use the santronics.com domain in the HELO/EHLO state: Reject if .santronics.com in .%CDN% and %CIP% != 208.247.131.9 In short, our recommendations in regards to LMAP based protocols, is that all systems should perform a strong check for local domain spoofs where 100% reliable results are known. LMAP checks on remote domains has high overhead concerns and less trust on the results. Currently, 1.2% rejection is realized using LMAP protocols. We expect this to change as more SPF domains are published. Finally, if a transaction SPF check result is indeterminate, then a final CBV check is performed by starting a SMTP-based call back to the email address host server. An average 40% rejection is realized with CBV. We are confident of the CBV method as a reliable method since it interoperates with the RFC 2821 SMTP standard requirement for a valid and verifiable return path We were not concern about CBV zombie sites and in the 2 years since we have it implemented, the zombie issue is rare, however, when it does occur, our CBV system implements a Open Relay check by checking if the zombie site will accept any return path address issued. If so, it is deemed as an open relay and it is rejected. However, we do realized that a wide adoption of a CBV concept may created a high overhead bandwidth issue with everyone calling back each system. But the proof of concept is unquestionable and we recommend more SMTP R&D for research call back methods to validate and verify a sender return path. It is important to realize that LMAP based methods only validate the domain portion, not the full address. So even if a LMAP method authorizes a return path such as "junkuser@microsoft.com" it does not authenticate the existence of the junkuser at microsoft.com. The CBV fills this validation requirement.

4-For our company domains, we use 1 quad CPU server for our Windows 2000 Server with a high-end RPC based multi-threaded mail server, two 80 gig drives. This is sufficient for our support system. We average 5500-6000 messages per day for over 30,000 support user accounts. Today, we estimate around 3000 customers are using our mail server which is not our main product line (over 100,000 customers world wide), However, of late, we seen an increase of companies switching to our mail server due to its strong Sender Authentication and backward compatibility considerations. We have had corporate network administrators state that WCSAP is very efficient compared to other similar systems who don't include all the WCSAP considerations During field testing, we had about 150 field testers spread across small to corporate systems. Early on we accumulated all logs and statistic to compare results and in summary there were no surprises. They all have similar results that reflects the single most fundamental fact: - Over 60-80% transactions are non-compliant SMTP sessions. and you can trap 94% or better of these bad transactions using SMTP based concepts, not payload concepts which concepts like SenderID/PRA promotes.

5-No special hardware other than what is required for scalability loads per system. For us, 1 high-end quad cpu Windows 2000 server machine was sufficient. However, since email authentication requires additional overhead on a per session basis, for our dynamic SMTP technology using wcSAP, a p-code compiled language is used to create WCSAP which hooks into each state of the SMTP state machine. p-code is faster than text based interpretive concepts usually used on other mail servers. Probably another consideration is dynamic vs post. For dynamic SMTP level email authentication, the configuration must be scaled to handle high concurrency loads. The scale is smaller for post smtp systems which accept the payload first before performing email authentication. Post SMTP systems are more problematic in the first against spam since it caters to the email bounce attacks due to the fact that RFC 2821 requires a level of delivery expectation which means either you delivery the mail to the user or you send a bounce back to the sender.

6-For our own single system, over 2 year span with an average of 5000 messages, over 4 million messages. For our customers, with an estimate of 3000 installations, using the same message rate, over 12,000 millions messages. We have ISPs world wide who process mail as high as 1 million per day.

7-Live real time email. No fabrication other then to satisfy test suites to analyze various email 2821/2822 scenarios that might not occur in practice but were possible. Our WCSAP system can be tested at: http://www.winserver.com/testwcsap We save all our mail so we are currently performing SenderID/PRA comparisons on these messages. Our initial goals will answer the questions and concerns regarding SenderID/PRA which are: 1) SenderID/PRA is a payload protocol. The PRA algorithm extracts the purported responsible address from the presence of Resent-Sender:, Resent-From:, Sender: or From: in the 2822 payload. How will the PRA extraction (accept payload and parse headers) compare to the 2821.Mail From address? So far, early analysis show for 88% of all transactions: 2822.PRA = 2821.MAIL FROM which reaffirms the idea that SenderID/PRA presents a clear high overhead potential for most transactions where the same results can be achieve at the 2821 SMTP level. 2) The second question is to estimate the payload size overhead difference. This is important because one of main security concerns with any payload email authentication concept, including Yahoo's Domainkeys or Cisco's IIM payload protocols, is that hackers and spammers will target these systems with higher payloads to frustrate systems with new scalability issues. Microsoft's direct response to this concern was basically stated as: "The payload increase is insignificant compared the benefits achieved with SenderID/PRA." I strongly disagree because I have not seen were the benefits over using a more efficient 2821 based email authentication concept.

8-From July 2003 to April 2004 when our WCSAP system was finally release to our customers. It was made available as a new optional component for our normal quarterly upgrades. See our 2 year statistics at: WcSAP Anti-Spam Stats http://www.winserver.com/spamstats Wildcat! Sender Authentication Protocol http://www.winserver.com/wcsap

9-Not realizing this incoming question was pending, I believe I might have answer this in the other questions. I guess, I would like to emphasize that it is our strong technical opinion that an email authentication solution should be based on making the SMTP transaction process stronger and begin to enforce SMTP compliancy. Payload based solutions like SenderID/PRA do not add any benefits but increase the inevitable potential for high payload abuse and increase new scalability problems. When you look inside the engine of SenderID/PRA, it is 100% based on the SPF protocol which is based on using SMTP level parameters. It makes absolutely no technical and logical sense whatsoever to ignore the 2821.MAIL FROM address when in fact, early analysis has showing 88% of the transactions will result with the same PRA value as the 2821.MAIL FROM address.

10-Base on statistics: http://www.winserver.com/spamstats Over ~92% of all transactions were rejected with 0 false positives. This is based the fundamental premise that over industry average of 60-80% of all transactions are bad. Since SPF is widely used within our customer base, 100% of our valid customer email is authenticated using SPF. Have we seen a growth of SPF zombie sites? Yes. We have seen more direct marketing organization and spammers begin to use SPF to validate their transaction. Our concern is not setting administrator or user level policy on mail content. Our main design concerns as SMTP mail developer is to secure the transaction at the SMTP level. Once the transactions are valid, issues regarding mail content interpretation can be addressed. The other issue in regards to using SPF is its relaxed SPF domain polices where a domain can relaxed its machine authorization with neutral or soft fail results (not hard pass or hard fail). Spammers can exploit this relaxed provisions and have. Our WCSAP systems views Neutral and Softfail SPF results as indeterminate and thus the CBV checking will be done. This is proved to trap the SPF spoofer exploiting SPF relaxed policies such as AOL.COM. A return path using aol.com will result in a Neutral result when the IP does not match the policy. This will trigger our final CBV check and typically the host will reject the return path. This illustrates the idea that SPF, including SENDERID/PRA do not authenticate the full email address, but only the domain part of the address, hence doing nothing for the sender address validation requirement mandated by the CAN-SPAM act.

11-Our fundamental design consideration and premise is that the majority of all transactions (over 60-80% by industry estimates) are problematic at the SMTP level due to one or more of the following reasons: - untested non-compliant SMTP client sender, - fake, bad or spoofed sender return address. When you apply a strong SMTP compliancy considerations, you will eliminate a majority population of the problematic email transactions. What remains are is a very small population of SMTP compliant transactions and to answer the question in regards to Spammers, Phishers or Zombies drones requires a new level of considerations such as: - Automated or user-requested blacklisting, (spammers, phishers) - Transaction rate pattern (compromised user machines, drones) - Mail Content Analysis (phishers) This is where Mail Integrity based ideas may be useful such as DomainKeys or IIM. But they also bring up a new level of software engineering considerations that conflicts with SMTP level vs PAYLOAD level analysis ideas. One thing for sure, SenderID/PRA does not add value in addressing either of these sender type classifications since its protocol is flawed based on it technical merits. SenderID/PRA ignores the high spoofed SMTP transactions rates. SenderID/PRA ignores the 2821 return addresses. SenderID/PRA mistakenly presumes 2822 compliancy SenderID/PRA increase payload bandwidth requirements. In any case, once a transaction has passed the strong SMTP WCSAP checking, the responsibility is moved to the administrators by providing a "skeleton hook" into the DATA state of the SMTP state machine. For our system, administrators add 3rd party mail content analyzing software such Spam Assassin or AVS software like McAfee, Norton, etc. The reason we do this is that the the mail content based rejections can be dynamic at the SMTP level. This reduces post smtp BOUNCE requirements.

12-Base on our June 2005 statistics thus far: see http://www.winserver.com/spamstats The average rejection at each point of the state machine is HELO/EHLO: 63.3% This means of the average 4674 incoming connections, 63.3% of them are rejected or they drop on their own for non-SMTP compliancy reasons. The reason breakdown: syntax error - 12% No support for multi-line 220 greeting lines: 41% The latter is because a majority of your bulk spammers are using non-compliant SMTP client software (like perl or php scripts) that blast the entire payload and ignore multiple 220 SMTP greeting lines. Of the remaining that reason the next MAIL FROM state: MAIL FROM: 30.7% are rejected, however, for our system, the MAIL FROM validation is delayed into the after the recipient address (RCPT TO) is known to eliminate the transactions which will never be delivered under any circumstance. This is major overhead redundancy consideration. So if the amount of the transaction that reach the RCPT TO state: RCPT TO: 58.5% Are rejected due to unknown user recipient address. This is very important and is critical to addressing the email authentication problem with new proposals with high backward compatibility considerations. In order to accept an recipient address that is not local host system, this is viewed as a routing or relay process. In order for a sender to route mail through a system, he must be authorized using traditional methods such as: - IP relay allow tables - ESMTP AUTH (extended SMTP login method) - POP3 B4 SMTP process. The above 3 method is the traditional method to authorized a sender to route mail through a system. Hence, if the sender is authorized using any of these traditional methods, then there a lesser requirement to impose a new email authentication system on an already authorized system. The #1 problem with SMTP is that it does not require authentication for local mail acceptance. This is what makes the system works, it is also what the spammers exploit. So in our view, any new email authentication concept will only apply to local mail or final destination mail. For our system, once the remaining transactions passe the RCPT TO, then WCSAP is processed to validate the MAIL FROM address. As pointed out above, 30.7% is rejected due to one of the WCSAP methods implemented. The breakdown is: FILTER: 5.2% RBL 69.4% LMAP 0.8% CBV: 23.0% Once the transactions WCSAP checks are done, the payload is received at the DATA state, which for our specific system, 16.5% is rejected due so some mail content spam reason. As stated, we believe mail content analysis is an administrative or site to site policy issue. Each system can choose to reject or move the mail to user junk boxes. Our concern the automated transaction management and security at the SMTP level where the bulk of the email exploitation is taken place.

13-This was described in detailed in previous questions. Here is a summary: Proposals based on SMTP level protocols will scale better than proposals based on PAYLOAD analysis. This is due to the simple industry estimated empirical facts, confirmed by our own statistics, that over 60-80% of all transactions are problem at the SMTP level. This is what the Spammers are exploiting - the unchecked transaction SMTP parameters. They rely on the SMTP behavior of systems not performing any kind of check for anonymous sender local final destination mail transactions. If a payload based proposal is endorsed, such as SenderID/PRA, I gravely predict that hackers and spammers will be able to frustrate systems because of the new scalability issues created by sending higher payload transactions.

14-For any LMAP based proposal that requires DNS look ups, there will be increase DNS overhead issues. For SenderID/PRA, there will be a high bandwidth payload potential problem since it relies on receiving the payload before performing the SENDERID/PRA check. There will a few considerations to make based on the possible adaption of malicious senders: 1) No Adaption, legacy clients. 2) Adaption. Clients adjust, add SPF DNS records 3) Spoofers. Clients piggyback on other SPF domains. With over 60-80% BAD transactions at the SMTP level, performing a blind check on each transaction will produce major DNS overhead and increase the transaction times. In additional, considering the fact that not all domains will be SPF ready and make a take a while before wide adoption is in place, you will have 3 types of DNS results: Bad Domain - NXDOMAIN (doesn't exist) Good Domain - No SPF record Good Domain - SPF record So you will have a higher DNS overhead issue with no practical result. The overall goal is to reduce the need to perform open-ended DNS lookups as much as possible by quickly disseminated the non-compliant SMTP clients from the good and only performing any new authentication concept when it is absolutely necessary.

15-We have a testing tool at: http://www.winserver.com/testwcsap It is self documented and it will test the basic SMTP parameters: IP address Machine Domain Name Return Path Address The test utility Using the methods described in earlier responses. It returns output in text or XML format.

17-Yes, SenderID/PRA is viewed an extended implemented of the already pre-existing prior art SPF protocol. And as I strongly stated and repeated a few times, we believe we gain a better efficient with SMTP level authentications. That means checking the 2821.MAIL FROM return path address before any payload based analysis considerations is made. In addition, as was pointed out in previous responses, early analysis is showing the 2822 PRA address is equal to the 2821 Mail From address 88% of the time. So we believe the PRA is redundant and problematic from a scalability statepoint, and since it is non-compliant with current email operations, it will not provide any added value in solving the email problem.

18-See response #17. However, most likely than not, if common sense does not prevail and Microsoft is allowed to push a flawed protocol into the market place, then of course, our customer base will have the final word. But it will absolutely not replace anything that is currently in place, including the raw SPF MAP methodology for SMTP based sender authorization, and since neither address the true email address validation idea, we will continue to use CBV as the key address validation concept. The R&D will continue, and I hope in the direction on protecting the transaction at the SMTP level. Not at the payload level. If PRA is added, it will be done as low priority optional augmentation to the existing system that resulted with as indeterminate condition. Since our early analysis shows that the PRA is equal to the MAIL FROM 88% of the time, we will explore what the remaining 12% represents. We hope to perform this analysis in the coming week.

19-Yes, we want to look at a Mail Integrity protocol. When the merged Yahoo/Cisco DKIM protocol specification is release, we will explore it. Again, we don't believe this change the fact that over 60-80% of all transactions are problematic and the the emphasis should be at the SMTP level, not the payload level. A DKIM payload concept is different from a SenderID/PRA because it addresses endpoint "mail integrity" ideas. SenderID/PRA does not. Finally, Santronics is currently in R&D for a new TMS <tm> (Transaction Management and Security) protocol which is radical in design yet has a major consideration for backward compatibility and migration. Once we resolve IP related concerns, it will published. The point is, we are not there yet. The R&D will continue. The FTC needs to look at all the issues and make sure we don't rush to a decision (SenderID/PRA) that really isn't "doing it" for anyone, but instead raises more concern than what it attempts to address. If it was anyone else than Microsoft, pushing SenderID/PRA would not get any consideration whatsoever due to its lack of technical merits. Since we are talking about the most powerful software company in the world, we must follow their lead including software vendors such as Santronics. I believe a lot of time will be wasted if people begin to implement SenderID/PRA believing it will address their email problem when in fact, it has the potential to make matters worst, but more importantly, it will directs attention away from where the real problem is at - the non-compliant SMTP transaction.

20-For the previously mentioned PRA analysis questions: 1) Perform more statistic testing of what percentage the PRA = MAIL FROM. So far, this is 88% of all transactions. 2) Perform analysis of what the remaining 12% means in terms of sender type classification and if possible, determine if there is an automation concept here for a Pass/Reject concept. We hope to have this analysis completed within the end of next week.