Comment Number: 516761-100006
Received: 6/24/2005 7:23:45 PM
Organization: Red Hat
Commenter: David Woodhouse
State: XX
Agency: Federal Trade Commission
Rule: Email Authentication Questionnaire
Docket ID: To Be Added
Attachment: 516761-100006.pdf Download Adobe Reader

Comments:

Answers to Specific Questions


1-BATV and CSV.

2-Minor syntactical changes to the reverse-path generated by BATV, because my implementation predates the BATV draft.

3-I operated a set of five email addresses (volunteers) using BATV for a year, starting with my own address in February of last year. All outgoing email traffic from these addresses had its reverse-path encoded, and no bounces were accepted to the unencoded version of those addresses. The users who volunteered to participate in the test are extremely heavy users of email and mailing lists; this was why they were keen to try the system. During the test, two mailing lists were observed to be problematic with respect to BATV. Firstly, ironically, the ses-devel@codeshare.ca list filters incoming email according to the reverse-path, not the header From: address. Thus my own posts were considered to be from a non-subscriber and rejected. Secondly, the openssh-devel@mindrot.org mailing list utilises an abusive TDMA challenge-response system which required daily responses. Other than those minor problems, the trial has been considered entirely successful. It is known that one can generated a 'fixed hashed address' for use with such problematic recipients. Since the problem has been so minor, I haven't actually bothered to implement that solution yet.

4-The environment is a cluster of four Linux hosts sited in England, Italy and Canada. The configuration can be observed at http://david.woodhou.se/eximconf/ They are mostly i386-class boxes ranging from a dual Pentium-200 to a dual Athlon 1800.

5-No specialised software was installed; the default capabilities of the Exim MTA were sufficient to allow BATV/SES and CSV to be implemented purely in its configuration. Ref. http://david.woodhou.se/eximconf/

6-Detailed records were not kept during the test period (which is still ongoing as the 'test' has been a resounding success). Over 1,000,000 messages.

7-Obviously some fabricated test messages were used to start with but the bulk of the test was with live traffic. Incoming messages failing authentication (by being a bounce to a non-BATV-signed version of an address) were rejected.

8-The first address to use BATV was in February of last year; 16 months ago.

10-Detailed statistics were not kept, and the majority of traffic was 'authenticated' since the majority of traffic is not bounce traffic.

11-Not a relevant question for BATV testing. BATV protects against bounces to faked mail, and almost no authenticated bounces were in response to spam/virus mail. The one or two exceptions to this were abusive virus scanning software which dangerously sends its rejection as a non-bounce message (i.e. not with 'MAIL FROM:<>'). These were reported as serious mail abuse to the upstream network provider when they happened.

12-A relatively small percentage of email traffic was not authenticated. These were bounces to the 'unencoded' addresses, from which the system is known never to _send_ mail. In all cases it will have failed because it was an attempt to send a bounce in response to a faked email, or because it was an SMTP callout attempting to verify the source address of an email which was being _offered_ to the remote mail server. It is impossible to disinguish between the two.

13-Detailed analysis of scalability was not undertaken. However, I do not believe that BATV would be anywhere near being the bottleneck for a mail system. Its scalability is at least as good as the rest of the system.

9-The original BATV/SES implementation used a fine-grained timestamp instead of changing only once a day. This interacted badly with greylisting and was changed so that only one reverse-path is used each day for each original sender address.

14-Neligible.

15-N/A

16-The BATV/SES implementation was done entirely in Exim configuration language and took a number of days to implement and test. The idea was born from discussion of the flaws of SPF and a search for an alternative approach which was less broken..

17-I will not be testing Sender ID. It shares the same fundamental flaw as SPF does -- it relies on assumed behaviour at forwarding sites which is not actually expected. It would have many false rejections.

18-http://david.woodhou.se/why-not-spf.html

19-I will test the merged solution which arises from DomainKeys/IIM.