Comment Number: 516761-100001
Received: 6/23/2005 11:24:07 PM
Organization: xyzzy
Commenter: Frank Ellermannn
State: XX
Agency: Federal Trade Commission
Rule: Email Authentication Questionnaire
Docket ID: To Be Added
No Attachments

Comments:

Answers to Specific Questions


1-Sender Policy Framework (v=spf1) draft-schlitt-spf-classic-02

2-Older specifications of v=spf1 proposed a "zone cut", where the SPF sender policy for claranet.de would cover subdomains like xyzzy.claranet.de In practice this turned out to be not implemented, and it was later (2005) also removed from Wayne Schlitt's drafts. A wildcard solution (two instead of one DNS record) solved the problem for all subdomains.

3-The test covered the subdomain xyzzy.claranet.de getting about 1000 bogus bounces, challenges, out of office mails, and other "backscatter" (caused by forged Return-Paths) per day starting March 2004. The v=spf1 policy with result FAIL was published in April. The wildcard covering xyzzy was published in May. The flood of backscatter dropped back to nearly zero at the end of August. The date may be related to the introduction of SpamAssassin version 3 supporting v=spf1 (classic SPF), "professional" spammers probably test their procedures with SpamAssassin. The "backscatter" stayed near almost zero since September until now with the notably exceptio of about 100 bounces caused by the short Sober-Q (German rightwing propaganda) epidemy in early 2005. The number of mails sent from this subdomain is fairly small, but includes many abuse desks and whois contact addresses especially for the period before September. The complete number of "false positives" over 15 months was one. One mail to a whois address was forwarded to another address checking v=spf1 against the unmodified original MAIL FROM, resultig in a FAIL for the iP of the forwarder (a registrar). That's working as designed, and it had roughly the same effect as the SMT error "551 user not local". Resending this one mail bypassed to the real receiver bypassed the problem withi a minute. So far v=spf1 with FAIL policy works exactly as expected. Serious problems with bogus PASS as well as bogus FAIL results are to be expected, if a v=spf1 sender policy is tested against other mail identities (notably the "PRA") not derived from the SMTP envelope (HELO or MAIL FROM).

4-Test environment: Several outbound MTAs at different e-mail providers (not only claranet.de) also including various mailing lists. The 2822- From address reflected the v=spf1 protected subdomain. The SMTP MAIL FROM corresponded to the used MTA, i.e. the tested subdomain with claranet.de MTAs. One MSA (mail submit agent) "enforced submission rights" as specified in RfC 2476 section 6.1: The MAIL FROM had to be set to conform to a user address at this provider. The 2822- From address could reflect an address in the tested subdomain. The MSA did not set an 2822-Sender address. Therefore "PRA" and MAIL FROM were different, testing the "PRA" for mail sent via this MSA would result in a bogus FAIL. One tested mailing list was a Sympa mailing list. This list uses its own MAIL FROM adding an Errors-To: header field for this adress. Therefore "PRA" and MAIL FROM were different, testig the "PRA" for mail sent via this list would result in a bogus FAIL. All pure v=spf1 procedures worked as expected and without any problem. Apparently nobody implements Sender-ID, there were no problems caused by bogus "PRA" results by interpreting a pure v=spf1 sender policy with the "PRA"-algorithm. Tested sender policies: xyzzy.claranet.de "v=spf1 redirect=claranet.de" claranet.de "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"

5-No special software or hardware was used.

6-About 180000 inbound "backscatter" mails until August. About 135000 inbound other mails over 15 months, this includes ordinary spam after filtering almost all mail worms. About 20000 outbound mails, including spam reports and mailing lists. Most mailing list mails relayed by a third party system also using a v=spf1 FAIL policy for its own MAIL FROM address.

7-All tested outbound mails were real mails. All tested inbound mails were real inbound mails after filtering mail worms.

8-From April 2004 until today, not intending to stop the testing. TTBOMK no public complaints from any claranet.de customer with a similar subdomain.

9-n/a

10-Unknown, the sender policy doesn't include a logging feature.

11-No successfully authenticated email was sent by spammers etc. The only way to do this would be abuse by another claranet.de customer forging a MAIL FROM of the tested sudomain. No such "cross-user forgery" (as explained in the v=spf1 drafts) was reported. A simple way to prevent this possibility would be to "enforce submission rights" as specified in section 6.1 of RfC 2476. Testing Sender-ID "PRA" against v=spf1 sender policies could cause bogus PASS results despite of any "enforced submission rights". Adding a 2822-Sender header field reflecting the MAIL FROM as specified in option 8.1 of RfC 2476 could fix this problem. OTOH manipulations of the mail body by an MSA without the prior consent of the sender is a serious privacy issue, it could be illegal under German laws.

12-All "backscatter" mails were obviously never tested by the receiving system, otherwise they'd reject it instead of sending a bounce to the forged MAIL FROM. Only two FAIL results were reported back to an address of the tested subdomain: One "false positive" caused by an old-style forwarding setup (see the prior explanation, it is essentially a sort of SMTP error 551 "user not local"). The other reported FAIL was an accident caused by a user of a BBS trying to report a erroneous virus classification to the manufacturer of the anti-virus software. For some obscure reasons this user managed it to forge a MAIL FROM of the tested domain. The AV-manufacturer rejected it as v=spf1 FAIL, therefore the BBS-MTA sent a bounce message. After an abuse report to the BBS the case was investigated and closed. In both cases the reported v=spf1 FAIL worked as designed.

13-While simple v=spf1 sender policies with a FAIL result like the tested policy offer a clear incentive for receivers to test v=spf1 policies and reject mails with a FAIL result, it is less clear why receivers should bother to test complex policies without a potential FAIL result. The latest v=spf1 drafts limit the worst cases significantly, this problem could be now addresssed by "user education" or more likely by providing better "sender policy setup wizards". The value of PASS results, especially a PASS for HELO tests, is not yet fully explored. One approach proposed by AOL is an "assume innocent until proven guilty" interpretation of PASS. That might be a better strategy than any C/R-systems (challenge-response) based on PASS results. Essentially a PASS without corresponding white- and black-list is useless. OTOH v=spf1 offers to create white- and black-lists based on a PASS for domains (or even mailbox addresses) in addition to the known but limited IP-based white- or black-lists. Although v=spf1 offers some baroque features like per-user- policies, FAIL-explanations, or the "ptr"-mechanism, it is also very flexible. Above all spammers are forced to respect at least FAIL policies, if they wish to reach their victims.

14-n/a (the test covered only publishing v=spf1 sender policies without logging DNS queries of the corresponding TXT records)

15-The only tool created was a simple script trying to modify very complex sender policies of third parties by moving some obvious FAIL results to the begin of their sender policy. In essence it allows to specify one or more IPv4 CIDRs with among others all "good" IPs, where "good" is determined by more expensive tests like ptr-mechanisms. For the receiver this means that a final FAIL or SOFTFAIL case is "expensive" (defined by DNS queries). The result was, that separate tools to compute the opposite of some "good" CIDRs for (SOFT)FAIL results at the begin of the policy before more "expensive" tests is a waste of time, v=spf1 already offers a simple way to get this effect: an.example. IN TXT "v=spf1 -include:not-me.an.example ... -all" Here "..." stands for some expensive tests. Adding "not-me" with a "v=spf1 -ip4:... -ip4:... +all" allows to match all IPs not belonging to the specified good IPv4-CIDRs, because they run into the final +all for "not-me". Therefore the -include:not-me mechanism returns a FAIL at the cost of one DNS-query (for the include) before more expensive tests indicated by "...".

16-Participation in the relevant SPF and IETF mailing lists pushing for the now available stable v=spf1 draft -02 at about 10 hours per week since May 2004 until today.

17-Sender-ID "PRA" is broken by design, because it abuses v=spf1 policies for tests that will result in bogus PASS and bogus FAIL results. By itself (using spf2.0/pra policies designed for "PRA") its value is utter dubious, among others it might not work for: - RfC 2476 MSAs enforcing submission rights (6.1) without setting a Sender (8.1) - mailing lists not setting a Sender (e.g. only Errors-To) - moderated newsgroups (mail from news server to moderator) - MUAs not showing the tested "PRA" (e.g. a Resent-Sender) Its value as "anti-phishing" tool for legacy (= all) MUAs is dubious, if "phishers" create bogus Resent-header fields. Unlike v=spf1 it does almost nothing against "backscatter". But the opposite is also true, v=spf1 does almost nothing against "phishing" for similar reasons, legacy MUAs don't display the tested Return-Path (MAIL FROM).

18-See previous answer. PRA-"experiments" with v=spf1 policies without the explicit consent of the publisher of the policy are unethical and abuse. Offering some "opt-out scheme" to justify this abuse of the installed v=spf1 base for another incompatible "PRA" test is unethical and abuse. Several proposals for an explicit "opt-in" for those who want it exist. The first v=spf1 policies were published almost one year before "PRA" was formulated. The problems are all well known, undisputed, published numerous times, identified by the former IETF MARID WG, and reported to the IESG again and again.

19-MTAMARK and SIQ are promising. Reputation systems combined with SPF and other standards by SIQ might help to reduce the overhead of different independent standards. CSV, SES, and DKIM might be also interesting. For normal simple cases SPF and CSV HELO-tests might be similar, but CSV also guarantees to be simple (unlike SPF). OTOH there's no much deployment, that might change depending on the abuse of v=spf1 by "PRA".

20-The test is completed as soon as a better way to prevent "forgeries" is available, or if the "PRA" abuse of v=spf1 causes too many bogus results like the loss of legit mail or dangerous new "phishing" opportunities.